From tjarvi at qbang.org Tue Sep 1 02:38:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 1 Sep 2009 02:38:40 -0600 (MDT) Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks Ilkka The problem should be resolved (confirmed from two locations). I'll be trying to hunt down a Snow Leopard box tomorrow evening as well. On Tue, 1 Sep 2009, Ilkka Myller wrote: > Hi, > > CVS server is reachable, but when trying anonymous login it replies: > > " > Fatal error, aborting. > anonymous: no such system user > " > > It seems that the anonymous cvs account is not yet properly configured on the > new system. > > -- > I > >> On Mon, 31 Aug 2009, Trent Jarvi wrote: >> >> The server has been beemed to another location for those experiencing >> routing problems. >> >> in bash: >> >> export CVSROOT=:pserver:anonymous at qbang.org:2401/var/cvs/cvsroot >> cvs login (no passwd) >> cvs co -r commapi-0-0-1 rxtx-devel >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Tue Sep 1 03:05:59 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 12:05:59 +0300 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks, The new CVS server works well :) I can also confirm that latest CVS version builds properly with unmodified Snow Leopard (Mac OS X 10.6) system: Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 gcc version 4.2.1 (Apple Inc. build 5646) Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) --> Resulting JNI library (Universal Binary): i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = 9d15fc488b301da8bf65b2c9456a7bbb --> Resulting JAR: RXTXComm.jar / 60942 bytes MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 Atleast it builds.. and probably works too. I have not tested that yet. -- I Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > The problem should be resolved (confirmed from two locations). I'll > be trying to hunt down a Snow Leopard box tomorrow evening as well. From jimmy.lee at emotum.com Tue Sep 1 05:07:19 2009 From: jimmy.lee at emotum.com (Jimmy Lee [emotum]) Date: Tue, 1 Sep 2009 21:07:19 +1000 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: <112685a90909010407i6054acb5tc2b12196797bfaf1@mail.gmail.com> Could we access to the binaries? Please :) 2009/9/1 Ilkka Myller > Thanks, > > The new CVS server works well :) > > I can also confirm that latest CVS version builds properly with unmodified > Snow Leopard (Mac OS X 10.6) system: > > Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_I386 i386 > gcc version 4.2.1 (Apple Inc. build 5646) > Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) > > > --> Resulting JNI library (Universal Binary): > > i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes > > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 > librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc > > MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = > 9d15fc488b301da8bf65b2c9456a7bbb > > > --> Resulting JAR: > > RXTXComm.jar / 60942 bytes > > MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 > > > > Atleast it builds.. and probably works too. I have not tested that yet. > > -- > I > > Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > > The problem should be resolved (confirmed from two locations). I'll be >> trying to hunt down a Snow Leopard box tomorrow evening as well. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Tue Sep 1 06:21:28 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Tue, 1 Sep 2009 08:21:28 -0400 (EDT) Subject: [Rxtx] Snow Leopard binaries Message-ID: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> +1 for binaries - pretty please with sugar on top... -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com From fredm at alum.mit.edu Tue Sep 1 06:24:17 2009 From: fredm at alum.mit.edu (Fred G. Martin) Date: Tue, 1 Sep 2009 08:24:17 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> Message-ID: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> You can find one here: http://iharder.sourceforge.net/current/java/ Also, you need to add yourself (any rxtx user) to the uucp group. Niutils don't exist, but dscl is a replacement. There is info for using it here: http://aplawrence.com/MacOSX/directory_services.html Fred On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Tue Sep 1 07:03:37 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Tue, 1 Sep 2009 18:33:37 +0530 Subject: [Rxtx] Help for RXTX on mac Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time I am able to read the device but on second time, it hangs on COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then it was showing the PortInUseException, I replaced the RXTX library to 2.2Pre1 so it is showing this problem. Is this is a problem with RXTX on Mac? Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: From ilkka at myller.com Tue Sep 1 09:57:06 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 16:57:06 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 10:02:31 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:02:31 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 10:43:49 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:43:49 +0300 Subject: [Rxtx] Help for RXTX on mac In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE@myller.com> Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Arseneau at Sun.COM Tue Sep 1 10:51:32 2009 From: Eric.Arseneau at Sun.COM (Eric Arseneau) Date: Tue, 01 Sep 2009 07:51:32 -0700 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24@sun.com> Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 11:24:30 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 18:24:30 +0300 Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D@myller.com> Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Tue Sep 1 02:38:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 1 Sep 2009 02:38:40 -0600 (MDT) Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks Ilkka The problem should be resolved (confirmed from two locations). I'll be trying to hunt down a Snow Leopard box tomorrow evening as well. On Tue, 1 Sep 2009, Ilkka Myller wrote: > Hi, > > CVS server is reachable, but when trying anonymous login it replies: > > " > Fatal error, aborting. > anonymous: no such system user > " > > It seems that the anonymous cvs account is not yet properly configured on the > new system. > > -- > I > >> On Mon, 31 Aug 2009, Trent Jarvi wrote: >> >> The server has been beemed to another location for those experiencing >> routing problems. >> >> in bash: >> >> export CVSROOT=:pserver:anonymous at qbang.org:2401/var/cvs/cvsroot >> cvs login (no passwd) >> cvs co -r commapi-0-0-1 rxtx-devel >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Tue Sep 1 03:05:59 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 12:05:59 +0300 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks, The new CVS server works well :) I can also confirm that latest CVS version builds properly with unmodified Snow Leopard (Mac OS X 10.6) system: Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 gcc version 4.2.1 (Apple Inc. build 5646) Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) --> Resulting JNI library (Universal Binary): i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = 9d15fc488b301da8bf65b2c9456a7bbb --> Resulting JAR: RXTXComm.jar / 60942 bytes MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 Atleast it builds.. and probably works too. I have not tested that yet. -- I Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > The problem should be resolved (confirmed from two locations). I'll > be trying to hunt down a Snow Leopard box tomorrow evening as well. From jimmy.lee at emotum.com Tue Sep 1 05:07:19 2009 From: jimmy.lee at emotum.com (Jimmy Lee [emotum]) Date: Tue, 1 Sep 2009 21:07:19 +1000 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: <112685a90909010407i6054acb5tc2b12196797bfaf1@mail.gmail.com> Could we access to the binaries? Please :) 2009/9/1 Ilkka Myller > Thanks, > > The new CVS server works well :) > > I can also confirm that latest CVS version builds properly with unmodified > Snow Leopard (Mac OS X 10.6) system: > > Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_I386 i386 > gcc version 4.2.1 (Apple Inc. build 5646) > Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) > > > --> Resulting JNI library (Universal Binary): > > i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes > > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 > librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc > > MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = > 9d15fc488b301da8bf65b2c9456a7bbb > > > --> Resulting JAR: > > RXTXComm.jar / 60942 bytes > > MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 > > > > Atleast it builds.. and probably works too. I have not tested that yet. > > -- > I > > Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > > The problem should be resolved (confirmed from two locations). I'll be >> trying to hunt down a Snow Leopard box tomorrow evening as well. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Tue Sep 1 06:21:28 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Tue, 1 Sep 2009 08:21:28 -0400 (EDT) Subject: [Rxtx] Snow Leopard binaries Message-ID: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> +1 for binaries - pretty please with sugar on top... -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com From fredm at alum.mit.edu Tue Sep 1 06:24:17 2009 From: fredm at alum.mit.edu (Fred G. Martin) Date: Tue, 1 Sep 2009 08:24:17 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> Message-ID: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> You can find one here: http://iharder.sourceforge.net/current/java/ Also, you need to add yourself (any rxtx user) to the uucp group. Niutils don't exist, but dscl is a replacement. There is info for using it here: http://aplawrence.com/MacOSX/directory_services.html Fred On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Tue Sep 1 07:03:37 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Tue, 1 Sep 2009 18:33:37 +0530 Subject: [Rxtx] Help for RXTX on mac Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time I am able to read the device but on second time, it hangs on COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then it was showing the PortInUseException, I replaced the RXTX library to 2.2Pre1 so it is showing this problem. Is this is a problem with RXTX on Mac? Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: From ilkka at myller.com Tue Sep 1 07:57:06 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 16:57:06 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:02:31 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:02:31 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:43:49 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:43:49 +0300 Subject: [Rxtx] Help for RXTX on mac In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE@myller.com> Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Arseneau at Sun.COM Tue Sep 1 08:51:32 2009 From: Eric.Arseneau at Sun.COM (Eric Arseneau) Date: Tue, 01 Sep 2009 07:51:32 -0700 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24@sun.com> Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 09:24:30 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 18:24:30 +0300 Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D@myller.com> Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Thu Sep 3 04:50:16 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Thu, 3 Sep 2009 10:50:16 +0200 Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s From Kapil_Gupta at hcl.in Thu Sep 3 08:52:21 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:22:21 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From Kapil_Gupta at hcl.in Thu Sep 3 09:15:19 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:45:19 +0530 Subject: [Rxtx] Rxtx Digest, Vol 25, Issue 3 In-Reply-To: References: Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C50BB@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi myller, I have attached the code with the mail. Please help me if I am doing something wrong in it. Thanks & Regards, Kapil Gupta -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of rxtx-request at qbang.org Sent: Thursday, September 03, 2009 4:15 PM To: rxtx at qbang.org Subject: Rxtx Digest, Vol 25, Issue 3 Send Rxtx mailing list submissions to rxtx at qbang.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qbang.org/mailman/listinfo/rxtx or, via email, send a message with subject or body 'help' to rxtx-request at qbang.org You can reach the person managing the list at rxtx-owner at qbang.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Rxtx digest..." Today's Topics: 1. Re: Snow Leopard binaries (Ilkka Myller) 2. Re: Snow Leopard binaries (Ilkka Myller) 3. Re: Help for RXTX on mac (Ilkka Myller) 4. Re: Snow Leopard binaries (Eric Arseneau) 5. Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters (Ilkka Myller) 6. RXTX multiple crashes (Kjetil ?ster?s) 7. RXTX 2.2Pre + MacMini+ Deadlock while second time port open (Kapil Gupta) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Sep 2009 16:57:06 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 1 Sep 2009 17:02:31 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <55EC133D-DC83-45A3-849C-02714904D580 at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 1 Sep 2009 17:43:49 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Help for RXTX on mac Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Tue, 01 Sep 2009 07:51:32 -0700 From: Eric Arseneau Cc: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24 at sun.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 1 Sep 2009 18:24:30 +0300 From: Ilkka Myller To: rxtx Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Thu, 3 Sep 2009 10:50:16 +0200 From: Kjetil ?ster?s To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s ------------------------------ Message: 7 Date: Thu, 3 Sep 2009 18:22:21 +0530 From: Kapil Gupta To: "rxtx at qbang.org" Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059 at NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset="us-ascii" Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: ------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx End of Rxtx Digest, Vol 25, Issue 3 *********************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From tjarvi at qbang.org Tue Sep 1 02:38:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 1 Sep 2009 02:38:40 -0600 (MDT) Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks Ilkka The problem should be resolved (confirmed from two locations). I'll be trying to hunt down a Snow Leopard box tomorrow evening as well. On Tue, 1 Sep 2009, Ilkka Myller wrote: > Hi, > > CVS server is reachable, but when trying anonymous login it replies: > > " > Fatal error, aborting. > anonymous: no such system user > " > > It seems that the anonymous cvs account is not yet properly configured on the > new system. > > -- > I > >> On Mon, 31 Aug 2009, Trent Jarvi wrote: >> >> The server has been beemed to another location for those experiencing >> routing problems. >> >> in bash: >> >> export CVSROOT=:pserver:anonymous at qbang.org:2401/var/cvs/cvsroot >> cvs login (no passwd) >> cvs co -r commapi-0-0-1 rxtx-devel >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Tue Sep 1 03:05:59 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 12:05:59 +0300 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks, The new CVS server works well :) I can also confirm that latest CVS version builds properly with unmodified Snow Leopard (Mac OS X 10.6) system: Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 gcc version 4.2.1 (Apple Inc. build 5646) Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) --> Resulting JNI library (Universal Binary): i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = 9d15fc488b301da8bf65b2c9456a7bbb --> Resulting JAR: RXTXComm.jar / 60942 bytes MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 Atleast it builds.. and probably works too. I have not tested that yet. -- I Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > The problem should be resolved (confirmed from two locations). I'll > be trying to hunt down a Snow Leopard box tomorrow evening as well. From jimmy.lee at emotum.com Tue Sep 1 05:07:19 2009 From: jimmy.lee at emotum.com (Jimmy Lee [emotum]) Date: Tue, 1 Sep 2009 21:07:19 +1000 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: <112685a90909010407i6054acb5tc2b12196797bfaf1@mail.gmail.com> Could we access to the binaries? Please :) 2009/9/1 Ilkka Myller > Thanks, > > The new CVS server works well :) > > I can also confirm that latest CVS version builds properly with unmodified > Snow Leopard (Mac OS X 10.6) system: > > Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_I386 i386 > gcc version 4.2.1 (Apple Inc. build 5646) > Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) > > > --> Resulting JNI library (Universal Binary): > > i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes > > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 > librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc > > MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = > 9d15fc488b301da8bf65b2c9456a7bbb > > > --> Resulting JAR: > > RXTXComm.jar / 60942 bytes > > MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 > > > > Atleast it builds.. and probably works too. I have not tested that yet. > > -- > I > > Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > > The problem should be resolved (confirmed from two locations). I'll be >> trying to hunt down a Snow Leopard box tomorrow evening as well. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Tue Sep 1 06:21:28 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Tue, 1 Sep 2009 08:21:28 -0400 (EDT) Subject: [Rxtx] Snow Leopard binaries Message-ID: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> +1 for binaries - pretty please with sugar on top... -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com From fredm at alum.mit.edu Tue Sep 1 06:24:17 2009 From: fredm at alum.mit.edu (Fred G. Martin) Date: Tue, 1 Sep 2009 08:24:17 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> Message-ID: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> You can find one here: http://iharder.sourceforge.net/current/java/ Also, you need to add yourself (any rxtx user) to the uucp group. Niutils don't exist, but dscl is a replacement. There is info for using it here: http://aplawrence.com/MacOSX/directory_services.html Fred On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Tue Sep 1 07:03:37 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Tue, 1 Sep 2009 18:33:37 +0530 Subject: [Rxtx] Help for RXTX on mac Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time I am able to read the device but on second time, it hangs on COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then it was showing the PortInUseException, I replaced the RXTX library to 2.2Pre1 so it is showing this problem. Is this is a problem with RXTX on Mac? Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: From ilkka at myller.com Tue Sep 1 07:57:06 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 16:57:06 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:02:31 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:02:31 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:43:49 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:43:49 +0300 Subject: [Rxtx] Help for RXTX on mac In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE@myller.com> Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Arseneau at Sun.COM Tue Sep 1 08:51:32 2009 From: Eric.Arseneau at Sun.COM (Eric Arseneau) Date: Tue, 01 Sep 2009 07:51:32 -0700 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24@sun.com> Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 09:24:30 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 18:24:30 +0300 Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D@myller.com> Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Thu Sep 3 02:50:16 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Thu, 3 Sep 2009 10:50:16 +0200 Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s From Kapil_Gupta at hcl.in Thu Sep 3 06:52:21 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:22:21 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From Kapil_Gupta at hcl.in Thu Sep 3 07:15:19 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:45:19 +0530 Subject: [Rxtx] Rxtx Digest, Vol 25, Issue 3 In-Reply-To: References: Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C50BB@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi myller, I have attached the code with the mail. Please help me if I am doing something wrong in it. Thanks & Regards, Kapil Gupta -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of rxtx-request at qbang.org Sent: Thursday, September 03, 2009 4:15 PM To: rxtx at qbang.org Subject: Rxtx Digest, Vol 25, Issue 3 Send Rxtx mailing list submissions to rxtx at qbang.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qbang.org/mailman/listinfo/rxtx or, via email, send a message with subject or body 'help' to rxtx-request at qbang.org You can reach the person managing the list at rxtx-owner at qbang.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Rxtx digest..." Today's Topics: 1. Re: Snow Leopard binaries (Ilkka Myller) 2. Re: Snow Leopard binaries (Ilkka Myller) 3. Re: Help for RXTX on mac (Ilkka Myller) 4. Re: Snow Leopard binaries (Eric Arseneau) 5. Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters (Ilkka Myller) 6. RXTX multiple crashes (Kjetil ?ster?s) 7. RXTX 2.2Pre + MacMini+ Deadlock while second time port open (Kapil Gupta) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Sep 2009 16:57:06 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 1 Sep 2009 17:02:31 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <55EC133D-DC83-45A3-849C-02714904D580 at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 1 Sep 2009 17:43:49 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Help for RXTX on mac Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Tue, 01 Sep 2009 07:51:32 -0700 From: Eric Arseneau Cc: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24 at sun.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 1 Sep 2009 18:24:30 +0300 From: Ilkka Myller To: rxtx Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Thu, 3 Sep 2009 10:50:16 +0200 From: Kjetil ?ster?s To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s ------------------------------ Message: 7 Date: Thu, 3 Sep 2009 18:22:21 +0530 From: Kapil Gupta To: "rxtx at qbang.org" Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059 at NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset="us-ascii" Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: ------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx End of Rxtx Digest, Vol 25, Issue 3 *********************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From ilkka at myller.com Thu Sep 3 13:17:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 3 Sep 2009 20:17:27 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <4520677F-E8F0-46F5-B4AD-3AD3A7C2AED3@myller.com> Hi Kapil, The code is incomplete and I did not find anything I could to test/ debug with this. I also tried to find the actual serial port opening, but found only a call to missing method which creates the SerialPort object (?): serialPort = getSerialPortConnection( COMPort, this.readEvent.getDeviceName(), SerialCommConfig.DEVICE1[SerialCommConfig.TIMEOUT], SerialCommConfig.DEVICE1[SerialCommConfig.BAUDRATE], SerialCommConfig.DEVICE1[SerialCommConfig.DATABITS], SerialCommConfig.DEVICE1[SerialCommConfig.STOPBITS], SerialCommConfig.DEVICE1[SerialCommConfig.PARITY] ); The class SerialCommConfig is missing too. If this is a part of the actual code you are using, please note that you are not actually closing the serial port. The call to close() method is commented out: try { // serialPort.close(); } catch (Exception ex) { ex.printStackTrace(); } Re-opening of the serial port wont work if you haven't properly closed it first. -- I > > I am using RXTX on Macintosh to communicate to my device. First time > the device responds well but on second time, it hangs on > COMPort.open (name, timeout). > > I have attached the source code in a file. Please help me. > > Thanks & Best Regards, > Kapil -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorton at intellimec.com Thu Sep 3 13:37:55 2009 From: dmorton at intellimec.com (Daniel Morton) Date: Thu, 3 Sep 2009 13:37:55 -0400 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. (I haven't tried previous version though). Daniel Morton Java/J2EE Developer Tel +1 519.745.8887 x4331 Email dmorton at intellimec.com www.intellimec.com | www.iLane.com | www.drivesync.com Intelligent Mechatronic Systems Inc. 435 King Street North Waterloo, ON N2J 2Z5 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s Sent: Thursday, September 03, 2009 4:50 AM To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. From alexanderkiel at gmx.net Fri Sep 4 04:29:15 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 10:29:15 +0200 Subject: [Rxtx] Official Javadoc Location Message-ID: <1252052955.4025.80.camel@T61-KIEL> Hi List, I wasn't able to find an official location of RXTX Javadoc accessible over HTTP. Maybe someone can link me to it. If there is no such location, I would like to see one. I like to link from my own Javadoc to such a location. Thanks Alexander - e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 05:19:25 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:19:25 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> Message-ID: <1252055965.4025.84.camel@T61-KIEL> Hi Michael, thanks for the pointer. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 09:48 +0100, Michael Tandy wrote: > RxTx javadoc: http://users.frii.com/jarvi/rxtx/doc/index.html > Javax interface RxTx duplicates javadoc: > http://java.sun.com/products/javacomm/reference/api/index.html > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 05:22:14 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:22:14 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> Message-ID: <1252056134.4025.87.camel@T61-KIEL> Hi Eike, thanks, but I need a direct package pointer so that Javadoc will link the gnu.io packages automatically to the right location. Michael has pointed me to http://users.frii.com/jarvi/rxtx/doc/index.html which has the gnu.io packages. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 11:04 +0200, Eike Hinderk J?rrens wrote: > Hi Alexander, > it seems to me that RXTX is implementing this API: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Kind regards, > Eike > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kjetilos at gmail.com Fri Sep 4 05:43:41 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 11:43:41 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> Message-ID: <7a803d460909040243ke4449ecucbe2cd8b15761746@mail.gmail.com> Hi Daniel, This is interesting, what type of application are you making? Is there a lot of signaling on different COM ports at the same time in your application? In our application we have 11 devices connected to different COM ports, 9 of these are in active use when the application is running. I'm wondering how to use the RXTX library version 2.1.7 in this scenario without causing it to crash. After adding more signaling on the COM ports in our application we have now experienced other crashes and it is natural to think that it has something to do with our way of using RXTX from several threads at the same time. So my question is are there any methods like read/write/flush/close that are not thread safe and should be handled with care? And similarly is the RXTXPort.SerialInputStream and RXTXPort.SerialOutputStream thread safe? 2009/9/3 Daniel Morton : > I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. ?(I haven't tried previous version though). > > Daniel Morton > Java/J2EE Developer > > Tel ? ?+1 519.745.8887 x4331 > Email ? ?dmorton at intellimec.com > > > www.intellimec.com ?| ?www.iLane.com ?| ?www.drivesync.com > > > > Intelligent Mechatronic Systems Inc. > 435 King Street North Waterloo, ON N2J 2Z5 > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s > Sent: Thursday, September 03, 2009 4:50 AM > To: rxtx at qbang.org > Subject: [Rxtx] RXTX multiple crashes > > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x7d0d] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0ce75800): ?JavaThread "Y Worker" daemon > [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 > > Registers: > EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 > ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 > EIP=0x10007d0d, EFLAGS=0x00010202 > > Top of Stack: (sp=0x0d7ff6d8) > 0x0d7ff6d8: ? 0d7ff700 00000000 00000000 00000000 > 0x0d7ff6e8: ? 02a2eae8 00000123 00002958 0d7ff718 > 0x0d7ff6f8: ? 7c830887 7c90d28a 7c8664b5 00000e2c > 0x0d7ff708: ? 00002958 00000000 00000000 7c90cffa > 0x0d7ff718: ? 7c809bdb 00002958 0d7ff758 00000e40 > 0x0d7ff728: ? 00002958 02bd0468 0ce75800 080e4ee0 > 0x0d7ff738: ? 00000000 00000000 00000000 00000000 > 0x0d7ff748: ? 00000000 00000000 00000014 7c90d09a > > Instructions: (pc=0x10007d0d) > 0x10007cfd: ? 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 > 0x10007d0d: ? 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 > > > Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x7d0d] > J ?gnu.io.RXTXPort.nativeDrain(Z)Z > J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > ... > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x9c55] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0cddf400): ?JavaThread "XXX Worker" daemon > [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 > > Registers: > EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 > ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 > EIP=0x10009c55, EFLAGS=0x00010206 > > Top of Stack: (sp=0x0bb8f830) > 0x0bb8f830: ? 00000000 00000000 c0000005 00000000 > 0x0bb8f840: ? 00000000 00f1f0a5 00000002 00000000 > 0x0bb8f850: ? 003a0100 0001003f 0bb8fb20 0b9ff918 > 0x0bb8f860: ? 00000000 00000000 0bb8fb68 0bb8fb20 > 0x0bb8f870: ? 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 > 0x0bb8f880: ? 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 > 0x0bb8f890: ? 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 > 0x0bb8f8a0: ? 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 > > Instructions: (pc=0x10009c55) > 0x10009c45: ? 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff > 0x10009c55: ? 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 > > > Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x9c55] > C ?[rxtxSerial.dll+0xa05e] > J ?gnu.io.RXTXPort.readByte()I > J ?gnu.io.RXTXPort$SerialInputStream.read()I > J ?java.io.FilterInputStream.read()I > ... > > -- > Kjetil ?ster?s > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kjetil ?ster?s From tjarvi at qbang.org Fri Sep 4 08:00:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Sep 2009 06:00:40 -0600 (MDT) Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x7d0d] > J gnu.io.RXTXPort.nativeDrain(Z)Z > J gnu.io.RXTXPort$SerialOutputStream.flush()V > Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x9c55] > C [rxtxSerial.dll+0xa05e] > J gnu.io.RXTXPort.readByte()I > J gnu.io.RXTXPort$SerialInputStream.read()I RXTX 2.1-7 has concurrency issues that will show upon multicore systems. These should be resolved in the 2.2 pre release. A user application could synchronize the read/write/open/close calls while using 2.1 to avoid the concurrency issue. The flush is probably following a write while the readByte is coming from read(byte b). The bugs existed in rxtx for a long time. I assume changes in the JVM and the presence of multicore systems exposed the issues. -- Trent Jarvi tjarvi at qbang.org From kjetilos at gmail.com Fri Sep 4 08:33:33 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 14:33:33 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <7a803d460909040533n1caf240y8168477a578bc45c@mail.gmail.com> Den 4. september 2009 14.00 skrev Trent Jarvi f?lgende: > > > On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > >> Hi >> >> We are using RXTX version 2.1.7 actively and lately we are having some >> issues with the RXTX library crashing. We are running a windows xp >> system with multiple COM ports where each COM port have a serial >> device connected. Lately we have increased the amount of signaling >> done over the COM ports and we are experiencing several odd crashes. I >> tried to search the mailinglist for something similar but was unable >> to find anything. At one time the RXTX crashed in the >> gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the >> gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack >> traces if someone is interested in having a look. Has anyone seen the >> same crashes? and does anyone know what can cause such crash? >> >> >> Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x7d0d] >> J ?gnu.io.RXTXPort.nativeDrain(Z)Z >> J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > >> Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x9c55] >> C ?[rxtxSerial.dll+0xa05e] >> J ?gnu.io.RXTXPort.readByte()I >> J ?gnu.io.RXTXPort$SerialInputStream.read()I > > > RXTX 2.1-7 has concurrency issues that will show upon multicore systems. > These should be resolved in the 2.2 pre release. ?A user application could > synchronize the read/write/open/close calls while using 2.1 to avoid the > concurrency issue. > > The flush is probably following a write while the readByte is coming from > read(byte b). > > The bugs existed in rxtx for a long time. ?I assume changes in the JVM and > the presence of multicore systems exposed the issues. > Ok, so we should look more into using a newer version of RXTX. The current version from the webpage is 2.2pre2, what is the stability status of this version. Is it good enough for use in a production environment? -- Kjetil ?ster?s From tjarvi at qbang.org Tue Sep 1 02:38:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 1 Sep 2009 02:38:40 -0600 (MDT) Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks Ilkka The problem should be resolved (confirmed from two locations). I'll be trying to hunt down a Snow Leopard box tomorrow evening as well. On Tue, 1 Sep 2009, Ilkka Myller wrote: > Hi, > > CVS server is reachable, but when trying anonymous login it replies: > > " > Fatal error, aborting. > anonymous: no such system user > " > > It seems that the anonymous cvs account is not yet properly configured on the > new system. > > -- > I > >> On Mon, 31 Aug 2009, Trent Jarvi wrote: >> >> The server has been beemed to another location for those experiencing >> routing problems. >> >> in bash: >> >> export CVSROOT=:pserver:anonymous at qbang.org:2401/var/cvs/cvsroot >> cvs login (no passwd) >> cvs co -r commapi-0-0-1 rxtx-devel >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Tue Sep 1 03:05:59 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 12:05:59 +0300 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks, The new CVS server works well :) I can also confirm that latest CVS version builds properly with unmodified Snow Leopard (Mac OS X 10.6) system: Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 gcc version 4.2.1 (Apple Inc. build 5646) Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) --> Resulting JNI library (Universal Binary): i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = 9d15fc488b301da8bf65b2c9456a7bbb --> Resulting JAR: RXTXComm.jar / 60942 bytes MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 Atleast it builds.. and probably works too. I have not tested that yet. -- I Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > The problem should be resolved (confirmed from two locations). I'll > be trying to hunt down a Snow Leopard box tomorrow evening as well. From jimmy.lee at emotum.com Tue Sep 1 05:07:19 2009 From: jimmy.lee at emotum.com (Jimmy Lee [emotum]) Date: Tue, 1 Sep 2009 21:07:19 +1000 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: <112685a90909010407i6054acb5tc2b12196797bfaf1@mail.gmail.com> Could we access to the binaries? Please :) 2009/9/1 Ilkka Myller > Thanks, > > The new CVS server works well :) > > I can also confirm that latest CVS version builds properly with unmodified > Snow Leopard (Mac OS X 10.6) system: > > Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_I386 i386 > gcc version 4.2.1 (Apple Inc. build 5646) > Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) > > > --> Resulting JNI library (Universal Binary): > > i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes > > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 > librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc > > MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = > 9d15fc488b301da8bf65b2c9456a7bbb > > > --> Resulting JAR: > > RXTXComm.jar / 60942 bytes > > MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 > > > > Atleast it builds.. and probably works too. I have not tested that yet. > > -- > I > > Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > > The problem should be resolved (confirmed from two locations). I'll be >> trying to hunt down a Snow Leopard box tomorrow evening as well. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Tue Sep 1 06:21:28 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Tue, 1 Sep 2009 08:21:28 -0400 (EDT) Subject: [Rxtx] Snow Leopard binaries Message-ID: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> +1 for binaries - pretty please with sugar on top... -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com From fredm at alum.mit.edu Tue Sep 1 06:24:17 2009 From: fredm at alum.mit.edu (Fred G. Martin) Date: Tue, 1 Sep 2009 08:24:17 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> Message-ID: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> You can find one here: http://iharder.sourceforge.net/current/java/ Also, you need to add yourself (any rxtx user) to the uucp group. Niutils don't exist, but dscl is a replacement. There is info for using it here: http://aplawrence.com/MacOSX/directory_services.html Fred On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Tue Sep 1 07:03:37 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Tue, 1 Sep 2009 18:33:37 +0530 Subject: [Rxtx] Help for RXTX on mac Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time I am able to read the device but on second time, it hangs on COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then it was showing the PortInUseException, I replaced the RXTX library to 2.2Pre1 so it is showing this problem. Is this is a problem with RXTX on Mac? Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: From ilkka at myller.com Tue Sep 1 07:57:06 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 16:57:06 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:02:31 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:02:31 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:43:49 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:43:49 +0300 Subject: [Rxtx] Help for RXTX on mac In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE@myller.com> Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Arseneau at Sun.COM Tue Sep 1 08:51:32 2009 From: Eric.Arseneau at Sun.COM (Eric Arseneau) Date: Tue, 01 Sep 2009 07:51:32 -0700 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24@sun.com> Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 09:24:30 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 18:24:30 +0300 Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D@myller.com> Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Thu Sep 3 02:50:16 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Thu, 3 Sep 2009 10:50:16 +0200 Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s From Kapil_Gupta at hcl.in Thu Sep 3 06:52:21 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:22:21 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From Kapil_Gupta at hcl.in Thu Sep 3 07:15:19 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:45:19 +0530 Subject: [Rxtx] Rxtx Digest, Vol 25, Issue 3 In-Reply-To: References: Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C50BB@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi myller, I have attached the code with the mail. Please help me if I am doing something wrong in it. Thanks & Regards, Kapil Gupta -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of rxtx-request at qbang.org Sent: Thursday, September 03, 2009 4:15 PM To: rxtx at qbang.org Subject: Rxtx Digest, Vol 25, Issue 3 Send Rxtx mailing list submissions to rxtx at qbang.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qbang.org/mailman/listinfo/rxtx or, via email, send a message with subject or body 'help' to rxtx-request at qbang.org You can reach the person managing the list at rxtx-owner at qbang.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Rxtx digest..." Today's Topics: 1. Re: Snow Leopard binaries (Ilkka Myller) 2. Re: Snow Leopard binaries (Ilkka Myller) 3. Re: Help for RXTX on mac (Ilkka Myller) 4. Re: Snow Leopard binaries (Eric Arseneau) 5. Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters (Ilkka Myller) 6. RXTX multiple crashes (Kjetil ?ster?s) 7. RXTX 2.2Pre + MacMini+ Deadlock while second time port open (Kapil Gupta) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Sep 2009 16:57:06 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 1 Sep 2009 17:02:31 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <55EC133D-DC83-45A3-849C-02714904D580 at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 1 Sep 2009 17:43:49 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Help for RXTX on mac Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Tue, 01 Sep 2009 07:51:32 -0700 From: Eric Arseneau Cc: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24 at sun.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 1 Sep 2009 18:24:30 +0300 From: Ilkka Myller To: rxtx Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Thu, 3 Sep 2009 10:50:16 +0200 From: Kjetil ?ster?s To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s ------------------------------ Message: 7 Date: Thu, 3 Sep 2009 18:22:21 +0530 From: Kapil Gupta To: "rxtx at qbang.org" Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059 at NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset="us-ascii" Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: ------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx End of Rxtx Digest, Vol 25, Issue 3 *********************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From ilkka at myller.com Thu Sep 3 11:17:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 3 Sep 2009 20:17:27 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <4520677F-E8F0-46F5-B4AD-3AD3A7C2AED3@myller.com> Hi Kapil, The code is incomplete and I did not find anything I could to test/ debug with this. I also tried to find the actual serial port opening, but found only a call to missing method which creates the SerialPort object (?): serialPort = getSerialPortConnection( COMPort, this.readEvent.getDeviceName(), SerialCommConfig.DEVICE1[SerialCommConfig.TIMEOUT], SerialCommConfig.DEVICE1[SerialCommConfig.BAUDRATE], SerialCommConfig.DEVICE1[SerialCommConfig.DATABITS], SerialCommConfig.DEVICE1[SerialCommConfig.STOPBITS], SerialCommConfig.DEVICE1[SerialCommConfig.PARITY] ); The class SerialCommConfig is missing too. If this is a part of the actual code you are using, please note that you are not actually closing the serial port. The call to close() method is commented out: try { // serialPort.close(); } catch (Exception ex) { ex.printStackTrace(); } Re-opening of the serial port wont work if you haven't properly closed it first. -- I > > I am using RXTX on Macintosh to communicate to my device. First time > the device responds well but on second time, it hangs on > COMPort.open (name, timeout). > > I have attached the source code in a file. Please help me. > > Thanks & Best Regards, > Kapil -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorton at intellimec.com Thu Sep 3 11:37:55 2009 From: dmorton at intellimec.com (Daniel Morton) Date: Thu, 3 Sep 2009 13:37:55 -0400 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. (I haven't tried previous version though). Daniel Morton Java/J2EE Developer Tel +1 519.745.8887 x4331 Email dmorton at intellimec.com www.intellimec.com | www.iLane.com | www.drivesync.com Intelligent Mechatronic Systems Inc. 435 King Street North Waterloo, ON N2J 2Z5 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s Sent: Thursday, September 03, 2009 4:50 AM To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. From alexanderkiel at gmx.net Fri Sep 4 02:29:15 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 10:29:15 +0200 Subject: [Rxtx] Official Javadoc Location Message-ID: <1252052955.4025.80.camel@T61-KIEL> Hi List, I wasn't able to find an official location of RXTX Javadoc accessible over HTTP. Maybe someone can link me to it. If there is no such location, I would like to see one. I like to link from my own Javadoc to such a location. Thanks Alexander - e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:19:25 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:19:25 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> Message-ID: <1252055965.4025.84.camel@T61-KIEL> Hi Michael, thanks for the pointer. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 09:48 +0100, Michael Tandy wrote: > RxTx javadoc: http://users.frii.com/jarvi/rxtx/doc/index.html > Javax interface RxTx duplicates javadoc: > http://java.sun.com/products/javacomm/reference/api/index.html > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:22:14 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:22:14 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> Message-ID: <1252056134.4025.87.camel@T61-KIEL> Hi Eike, thanks, but I need a direct package pointer so that Javadoc will link the gnu.io packages automatically to the right location. Michael has pointed me to http://users.frii.com/jarvi/rxtx/doc/index.html which has the gnu.io packages. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 11:04 +0200, Eike Hinderk J?rrens wrote: > Hi Alexander, > it seems to me that RXTX is implementing this API: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Kind regards, > Eike > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kjetilos at gmail.com Fri Sep 4 03:43:41 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 11:43:41 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> Message-ID: <7a803d460909040243ke4449ecucbe2cd8b15761746@mail.gmail.com> Hi Daniel, This is interesting, what type of application are you making? Is there a lot of signaling on different COM ports at the same time in your application? In our application we have 11 devices connected to different COM ports, 9 of these are in active use when the application is running. I'm wondering how to use the RXTX library version 2.1.7 in this scenario without causing it to crash. After adding more signaling on the COM ports in our application we have now experienced other crashes and it is natural to think that it has something to do with our way of using RXTX from several threads at the same time. So my question is are there any methods like read/write/flush/close that are not thread safe and should be handled with care? And similarly is the RXTXPort.SerialInputStream and RXTXPort.SerialOutputStream thread safe? 2009/9/3 Daniel Morton : > I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. ?(I haven't tried previous version though). > > Daniel Morton > Java/J2EE Developer > > Tel ? ?+1 519.745.8887 x4331 > Email ? ?dmorton at intellimec.com > > > www.intellimec.com ?| ?www.iLane.com ?| ?www.drivesync.com > > > > Intelligent Mechatronic Systems Inc. > 435 King Street North Waterloo, ON N2J 2Z5 > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s > Sent: Thursday, September 03, 2009 4:50 AM > To: rxtx at qbang.org > Subject: [Rxtx] RXTX multiple crashes > > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x7d0d] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0ce75800): ?JavaThread "Y Worker" daemon > [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 > > Registers: > EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 > ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 > EIP=0x10007d0d, EFLAGS=0x00010202 > > Top of Stack: (sp=0x0d7ff6d8) > 0x0d7ff6d8: ? 0d7ff700 00000000 00000000 00000000 > 0x0d7ff6e8: ? 02a2eae8 00000123 00002958 0d7ff718 > 0x0d7ff6f8: ? 7c830887 7c90d28a 7c8664b5 00000e2c > 0x0d7ff708: ? 00002958 00000000 00000000 7c90cffa > 0x0d7ff718: ? 7c809bdb 00002958 0d7ff758 00000e40 > 0x0d7ff728: ? 00002958 02bd0468 0ce75800 080e4ee0 > 0x0d7ff738: ? 00000000 00000000 00000000 00000000 > 0x0d7ff748: ? 00000000 00000000 00000014 7c90d09a > > Instructions: (pc=0x10007d0d) > 0x10007cfd: ? 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 > 0x10007d0d: ? 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 > > > Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x7d0d] > J ?gnu.io.RXTXPort.nativeDrain(Z)Z > J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > ... > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x9c55] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0cddf400): ?JavaThread "XXX Worker" daemon > [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 > > Registers: > EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 > ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 > EIP=0x10009c55, EFLAGS=0x00010206 > > Top of Stack: (sp=0x0bb8f830) > 0x0bb8f830: ? 00000000 00000000 c0000005 00000000 > 0x0bb8f840: ? 00000000 00f1f0a5 00000002 00000000 > 0x0bb8f850: ? 003a0100 0001003f 0bb8fb20 0b9ff918 > 0x0bb8f860: ? 00000000 00000000 0bb8fb68 0bb8fb20 > 0x0bb8f870: ? 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 > 0x0bb8f880: ? 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 > 0x0bb8f890: ? 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 > 0x0bb8f8a0: ? 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 > > Instructions: (pc=0x10009c55) > 0x10009c45: ? 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff > 0x10009c55: ? 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 > > > Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x9c55] > C ?[rxtxSerial.dll+0xa05e] > J ?gnu.io.RXTXPort.readByte()I > J ?gnu.io.RXTXPort$SerialInputStream.read()I > J ?java.io.FilterInputStream.read()I > ... > > -- > Kjetil ?ster?s > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kjetil ?ster?s From tjarvi at qbang.org Fri Sep 4 06:00:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Sep 2009 06:00:40 -0600 (MDT) Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x7d0d] > J gnu.io.RXTXPort.nativeDrain(Z)Z > J gnu.io.RXTXPort$SerialOutputStream.flush()V > Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x9c55] > C [rxtxSerial.dll+0xa05e] > J gnu.io.RXTXPort.readByte()I > J gnu.io.RXTXPort$SerialInputStream.read()I RXTX 2.1-7 has concurrency issues that will show upon multicore systems. These should be resolved in the 2.2 pre release. A user application could synchronize the read/write/open/close calls while using 2.1 to avoid the concurrency issue. The flush is probably following a write while the readByte is coming from read(byte b). The bugs existed in rxtx for a long time. I assume changes in the JVM and the presence of multicore systems exposed the issues. -- Trent Jarvi tjarvi at qbang.org From kjetilos at gmail.com Fri Sep 4 06:33:33 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 14:33:33 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <7a803d460909040533n1caf240y8168477a578bc45c@mail.gmail.com> Den 4. september 2009 14.00 skrev Trent Jarvi f?lgende: > > > On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > >> Hi >> >> We are using RXTX version 2.1.7 actively and lately we are having some >> issues with the RXTX library crashing. We are running a windows xp >> system with multiple COM ports where each COM port have a serial >> device connected. Lately we have increased the amount of signaling >> done over the COM ports and we are experiencing several odd crashes. I >> tried to search the mailinglist for something similar but was unable >> to find anything. At one time the RXTX crashed in the >> gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the >> gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack >> traces if someone is interested in having a look. Has anyone seen the >> same crashes? and does anyone know what can cause such crash? >> >> >> Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x7d0d] >> J ?gnu.io.RXTXPort.nativeDrain(Z)Z >> J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > >> Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x9c55] >> C ?[rxtxSerial.dll+0xa05e] >> J ?gnu.io.RXTXPort.readByte()I >> J ?gnu.io.RXTXPort$SerialInputStream.read()I > > > RXTX 2.1-7 has concurrency issues that will show upon multicore systems. > These should be resolved in the 2.2 pre release. ?A user application could > synchronize the read/write/open/close calls while using 2.1 to avoid the > concurrency issue. > > The flush is probably following a write while the readByte is coming from > read(byte b). > > The bugs existed in rxtx for a long time. ?I assume changes in the JVM and > the presence of multicore systems exposed the issues. > Ok, so we should look more into using a newer version of RXTX. The current version from the webpage is 2.2pre2, what is the stability status of this version. Is it good enough for use in a production environment? -- Kjetil ?ster?s From martinezrodolfo at gmail.com Fri Sep 4 15:39:57 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Fri, 4 Sep 2009 15:09:57 -0430 Subject: [Rxtx] Problem with data available event Message-ID: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Hello list members. I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a serial port USB adapter to communicate with an electronical inmunoassay analyzer. The program works porperly with one model of the analyzer series. It defines a protocol which every message sent should be replied with an ACK in order to continue with the communication. Now we are trying to communicate with another model of the same brand and series wich in theory should be much of the same of what was previously done. Unfortunately, that is not the case. The problem with this connection is that it never fires the Data Available serial port event. Is like if nothing was being received in the input stream. The following code always prints zero when the equipment should be transmitting. ----------------------- beginning of sample code ---------------------------------- SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", 10000); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); int len = 0; byte[] readBuffer = new byte[8]; while (true) { len = in.read(readBuffer); System.out.println(len); writer.writeACK(); // writing ACK to analyzer } ----------------------- end of sample code ------------------------------------------ We know that the analyzer is transmitting because HyperTerminal does shows the proper output. In fact, after running the above code and connecting via Hyperterminal all data is received in one block. Is like the data sent from the analyzer is being held somewhere in the way. Sniffing at the serial port, noticed that IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this helps to find what might be wrong or not, but here they are: On Hyperterminal: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 XonLimit:80 XoffLimit:200 On Java: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 XonLimit:0 XoffLimit:0 Thanks in advance for your help. Rodolfo M From ilkka at myller.com Sat Sep 5 06:36:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 5 Sep 2009 13:36:27 +0300 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <121198EE-65A4-463B-ACC7-29FFB9855B2C@myller.com> Hi Rodolfo, By default RXTX does not enable any flow control for the serial port. Please check what flow control you have active in HyperTerminal when you are able to receive data and then use the same flow control with RXTX serial port: serialPort.setFlowControlMode(int flowcontrol); Possible flowcontrol flags are (from SerialPort class) FLOWCONTROL_NONE FLOWCONTROL_RTSCTS_IN FLOWCONTROL_RTSCTS_OUT FLOWCONTROL_XONXOFF_IN FLOWCONTROL_XONXOFF_OUT For example, you can try enabling RTS/CTS hardware flow control. Note the bitwise OR operator ' | ': serialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Also if your device requires RTS/CTS flow control make sure you have fully connected serial cable (not just RX, TX, GND for example, but also RTS, CTS, DTR). One thing you might want to check is the state of DTR (Data Terminal Ready). Some devices wait for the DTR signal before they send any data. You can enable or disable DTR signal (high/low) with: serialPort.setDTR( boolean state ); -- I > Hello list members. > > I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a > serial port USB adapter to communicate with an electronical > inmunoassay analyzer. The program works porperly with one model of the > analyzer series. It defines a protocol which every message sent should > be replied with an ACK in order to continue with the communication. > Now we are trying to communicate with another model of the same brand > and series wich in theory should be much of the same of what was > previously done. Unfortunately, that is not the case. The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. > > ----------------------- beginning of sample code > ---------------------------------- > SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", > 10000); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > InputStream in = serialPort.getInputStream(); > OutputStream out = serialPort.getOutputStream(); > > int len = 0; > byte[] readBuffer = new byte[8]; > while (true) { > len = in.read(readBuffer); > System.out.println(len); > > writer.writeACK(); // writing ACK to analyzer > } > ----------------------- end of sample code > ------------------------------------------ > > We know that the analyzer is transmitting because HyperTerminal does > shows the proper output. In fact, after running the above code and > connecting via Hyperterminal all data is received in one block. Is > like the data sent from the analyzer is being held somewhere in the > way. Sniffing at the serial port, noticed that > IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this > helps to find what might be wrong or not, but here they are: > > On Hyperterminal: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 > XonLimit:80 XoffLimit:200 > > On Java: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 > XonLimit:0 XoffLimit:0 > > > Thanks in advance for your help. > Rodolfo M > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Tue Sep 1 02:38:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 1 Sep 2009 02:38:40 -0600 (MDT) Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks Ilkka The problem should be resolved (confirmed from two locations). I'll be trying to hunt down a Snow Leopard box tomorrow evening as well. On Tue, 1 Sep 2009, Ilkka Myller wrote: > Hi, > > CVS server is reachable, but when trying anonymous login it replies: > > " > Fatal error, aborting. > anonymous: no such system user > " > > It seems that the anonymous cvs account is not yet properly configured on the > new system. > > -- > I > >> On Mon, 31 Aug 2009, Trent Jarvi wrote: >> >> The server has been beemed to another location for those experiencing >> routing problems. >> >> in bash: >> >> export CVSROOT=:pserver:anonymous at qbang.org:2401/var/cvs/cvsroot >> cvs login (no passwd) >> cvs co -r commapi-0-0-1 rxtx-devel >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Tue Sep 1 03:05:59 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 12:05:59 +0300 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks, The new CVS server works well :) I can also confirm that latest CVS version builds properly with unmodified Snow Leopard (Mac OS X 10.6) system: Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 gcc version 4.2.1 (Apple Inc. build 5646) Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) --> Resulting JNI library (Universal Binary): i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = 9d15fc488b301da8bf65b2c9456a7bbb --> Resulting JAR: RXTXComm.jar / 60942 bytes MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 Atleast it builds.. and probably works too. I have not tested that yet. -- I Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > The problem should be resolved (confirmed from two locations). I'll > be trying to hunt down a Snow Leopard box tomorrow evening as well. From jimmy.lee at emotum.com Tue Sep 1 05:07:19 2009 From: jimmy.lee at emotum.com (Jimmy Lee [emotum]) Date: Tue, 1 Sep 2009 21:07:19 +1000 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: <112685a90909010407i6054acb5tc2b12196797bfaf1@mail.gmail.com> Could we access to the binaries? Please :) 2009/9/1 Ilkka Myller > Thanks, > > The new CVS server works well :) > > I can also confirm that latest CVS version builds properly with unmodified > Snow Leopard (Mac OS X 10.6) system: > > Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_I386 i386 > gcc version 4.2.1 (Apple Inc. build 5646) > Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) > > > --> Resulting JNI library (Universal Binary): > > i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes > > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 > librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc > > MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = > 9d15fc488b301da8bf65b2c9456a7bbb > > > --> Resulting JAR: > > RXTXComm.jar / 60942 bytes > > MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 > > > > Atleast it builds.. and probably works too. I have not tested that yet. > > -- > I > > Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > > The problem should be resolved (confirmed from two locations). I'll be >> trying to hunt down a Snow Leopard box tomorrow evening as well. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Tue Sep 1 06:21:28 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Tue, 1 Sep 2009 08:21:28 -0400 (EDT) Subject: [Rxtx] Snow Leopard binaries Message-ID: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> +1 for binaries - pretty please with sugar on top... -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com From fredm at alum.mit.edu Tue Sep 1 06:24:17 2009 From: fredm at alum.mit.edu (Fred G. Martin) Date: Tue, 1 Sep 2009 08:24:17 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> Message-ID: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> You can find one here: http://iharder.sourceforge.net/current/java/ Also, you need to add yourself (any rxtx user) to the uucp group. Niutils don't exist, but dscl is a replacement. There is info for using it here: http://aplawrence.com/MacOSX/directory_services.html Fred On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Tue Sep 1 07:03:37 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Tue, 1 Sep 2009 18:33:37 +0530 Subject: [Rxtx] Help for RXTX on mac Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time I am able to read the device but on second time, it hangs on COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then it was showing the PortInUseException, I replaced the RXTX library to 2.2Pre1 so it is showing this problem. Is this is a problem with RXTX on Mac? Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: From ilkka at myller.com Tue Sep 1 07:57:06 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 16:57:06 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:02:31 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:02:31 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:43:49 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:43:49 +0300 Subject: [Rxtx] Help for RXTX on mac In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE@myller.com> Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Arseneau at Sun.COM Tue Sep 1 08:51:32 2009 From: Eric.Arseneau at Sun.COM (Eric Arseneau) Date: Tue, 01 Sep 2009 07:51:32 -0700 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24@sun.com> Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 09:24:30 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 18:24:30 +0300 Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D@myller.com> Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Thu Sep 3 02:50:16 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Thu, 3 Sep 2009 10:50:16 +0200 Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s From Kapil_Gupta at hcl.in Thu Sep 3 06:52:21 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:22:21 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From Kapil_Gupta at hcl.in Thu Sep 3 07:15:19 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:45:19 +0530 Subject: [Rxtx] Rxtx Digest, Vol 25, Issue 3 In-Reply-To: References: Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C50BB@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi myller, I have attached the code with the mail. Please help me if I am doing something wrong in it. Thanks & Regards, Kapil Gupta -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of rxtx-request at qbang.org Sent: Thursday, September 03, 2009 4:15 PM To: rxtx at qbang.org Subject: Rxtx Digest, Vol 25, Issue 3 Send Rxtx mailing list submissions to rxtx at qbang.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qbang.org/mailman/listinfo/rxtx or, via email, send a message with subject or body 'help' to rxtx-request at qbang.org You can reach the person managing the list at rxtx-owner at qbang.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Rxtx digest..." Today's Topics: 1. Re: Snow Leopard binaries (Ilkka Myller) 2. Re: Snow Leopard binaries (Ilkka Myller) 3. Re: Help for RXTX on mac (Ilkka Myller) 4. Re: Snow Leopard binaries (Eric Arseneau) 5. Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters (Ilkka Myller) 6. RXTX multiple crashes (Kjetil ?ster?s) 7. RXTX 2.2Pre + MacMini+ Deadlock while second time port open (Kapil Gupta) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Sep 2009 16:57:06 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 1 Sep 2009 17:02:31 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <55EC133D-DC83-45A3-849C-02714904D580 at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 1 Sep 2009 17:43:49 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Help for RXTX on mac Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Tue, 01 Sep 2009 07:51:32 -0700 From: Eric Arseneau Cc: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24 at sun.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 1 Sep 2009 18:24:30 +0300 From: Ilkka Myller To: rxtx Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Thu, 3 Sep 2009 10:50:16 +0200 From: Kjetil ?ster?s To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s ------------------------------ Message: 7 Date: Thu, 3 Sep 2009 18:22:21 +0530 From: Kapil Gupta To: "rxtx at qbang.org" Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059 at NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset="us-ascii" Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: ------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx End of Rxtx Digest, Vol 25, Issue 3 *********************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From ilkka at myller.com Thu Sep 3 11:17:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 3 Sep 2009 20:17:27 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <4520677F-E8F0-46F5-B4AD-3AD3A7C2AED3@myller.com> Hi Kapil, The code is incomplete and I did not find anything I could to test/ debug with this. I also tried to find the actual serial port opening, but found only a call to missing method which creates the SerialPort object (?): serialPort = getSerialPortConnection( COMPort, this.readEvent.getDeviceName(), SerialCommConfig.DEVICE1[SerialCommConfig.TIMEOUT], SerialCommConfig.DEVICE1[SerialCommConfig.BAUDRATE], SerialCommConfig.DEVICE1[SerialCommConfig.DATABITS], SerialCommConfig.DEVICE1[SerialCommConfig.STOPBITS], SerialCommConfig.DEVICE1[SerialCommConfig.PARITY] ); The class SerialCommConfig is missing too. If this is a part of the actual code you are using, please note that you are not actually closing the serial port. The call to close() method is commented out: try { // serialPort.close(); } catch (Exception ex) { ex.printStackTrace(); } Re-opening of the serial port wont work if you haven't properly closed it first. -- I > > I am using RXTX on Macintosh to communicate to my device. First time > the device responds well but on second time, it hangs on > COMPort.open (name, timeout). > > I have attached the source code in a file. Please help me. > > Thanks & Best Regards, > Kapil -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorton at intellimec.com Thu Sep 3 11:37:55 2009 From: dmorton at intellimec.com (Daniel Morton) Date: Thu, 3 Sep 2009 13:37:55 -0400 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. (I haven't tried previous version though). Daniel Morton Java/J2EE Developer Tel +1 519.745.8887 x4331 Email dmorton at intellimec.com www.intellimec.com | www.iLane.com | www.drivesync.com Intelligent Mechatronic Systems Inc. 435 King Street North Waterloo, ON N2J 2Z5 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s Sent: Thursday, September 03, 2009 4:50 AM To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. From alexanderkiel at gmx.net Fri Sep 4 02:29:15 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 10:29:15 +0200 Subject: [Rxtx] Official Javadoc Location Message-ID: <1252052955.4025.80.camel@T61-KIEL> Hi List, I wasn't able to find an official location of RXTX Javadoc accessible over HTTP. Maybe someone can link me to it. If there is no such location, I would like to see one. I like to link from my own Javadoc to such a location. Thanks Alexander - e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:19:25 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:19:25 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> Message-ID: <1252055965.4025.84.camel@T61-KIEL> Hi Michael, thanks for the pointer. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 09:48 +0100, Michael Tandy wrote: > RxTx javadoc: http://users.frii.com/jarvi/rxtx/doc/index.html > Javax interface RxTx duplicates javadoc: > http://java.sun.com/products/javacomm/reference/api/index.html > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:22:14 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:22:14 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> Message-ID: <1252056134.4025.87.camel@T61-KIEL> Hi Eike, thanks, but I need a direct package pointer so that Javadoc will link the gnu.io packages automatically to the right location. Michael has pointed me to http://users.frii.com/jarvi/rxtx/doc/index.html which has the gnu.io packages. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 11:04 +0200, Eike Hinderk J?rrens wrote: > Hi Alexander, > it seems to me that RXTX is implementing this API: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Kind regards, > Eike > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kjetilos at gmail.com Fri Sep 4 03:43:41 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 11:43:41 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> Message-ID: <7a803d460909040243ke4449ecucbe2cd8b15761746@mail.gmail.com> Hi Daniel, This is interesting, what type of application are you making? Is there a lot of signaling on different COM ports at the same time in your application? In our application we have 11 devices connected to different COM ports, 9 of these are in active use when the application is running. I'm wondering how to use the RXTX library version 2.1.7 in this scenario without causing it to crash. After adding more signaling on the COM ports in our application we have now experienced other crashes and it is natural to think that it has something to do with our way of using RXTX from several threads at the same time. So my question is are there any methods like read/write/flush/close that are not thread safe and should be handled with care? And similarly is the RXTXPort.SerialInputStream and RXTXPort.SerialOutputStream thread safe? 2009/9/3 Daniel Morton : > I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. ?(I haven't tried previous version though). > > Daniel Morton > Java/J2EE Developer > > Tel ? ?+1 519.745.8887 x4331 > Email ? ?dmorton at intellimec.com > > > www.intellimec.com ?| ?www.iLane.com ?| ?www.drivesync.com > > > > Intelligent Mechatronic Systems Inc. > 435 King Street North Waterloo, ON N2J 2Z5 > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s > Sent: Thursday, September 03, 2009 4:50 AM > To: rxtx at qbang.org > Subject: [Rxtx] RXTX multiple crashes > > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x7d0d] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0ce75800): ?JavaThread "Y Worker" daemon > [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 > > Registers: > EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 > ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 > EIP=0x10007d0d, EFLAGS=0x00010202 > > Top of Stack: (sp=0x0d7ff6d8) > 0x0d7ff6d8: ? 0d7ff700 00000000 00000000 00000000 > 0x0d7ff6e8: ? 02a2eae8 00000123 00002958 0d7ff718 > 0x0d7ff6f8: ? 7c830887 7c90d28a 7c8664b5 00000e2c > 0x0d7ff708: ? 00002958 00000000 00000000 7c90cffa > 0x0d7ff718: ? 7c809bdb 00002958 0d7ff758 00000e40 > 0x0d7ff728: ? 00002958 02bd0468 0ce75800 080e4ee0 > 0x0d7ff738: ? 00000000 00000000 00000000 00000000 > 0x0d7ff748: ? 00000000 00000000 00000014 7c90d09a > > Instructions: (pc=0x10007d0d) > 0x10007cfd: ? 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 > 0x10007d0d: ? 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 > > > Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x7d0d] > J ?gnu.io.RXTXPort.nativeDrain(Z)Z > J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > ... > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x9c55] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0cddf400): ?JavaThread "XXX Worker" daemon > [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 > > Registers: > EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 > ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 > EIP=0x10009c55, EFLAGS=0x00010206 > > Top of Stack: (sp=0x0bb8f830) > 0x0bb8f830: ? 00000000 00000000 c0000005 00000000 > 0x0bb8f840: ? 00000000 00f1f0a5 00000002 00000000 > 0x0bb8f850: ? 003a0100 0001003f 0bb8fb20 0b9ff918 > 0x0bb8f860: ? 00000000 00000000 0bb8fb68 0bb8fb20 > 0x0bb8f870: ? 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 > 0x0bb8f880: ? 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 > 0x0bb8f890: ? 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 > 0x0bb8f8a0: ? 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 > > Instructions: (pc=0x10009c55) > 0x10009c45: ? 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff > 0x10009c55: ? 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 > > > Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x9c55] > C ?[rxtxSerial.dll+0xa05e] > J ?gnu.io.RXTXPort.readByte()I > J ?gnu.io.RXTXPort$SerialInputStream.read()I > J ?java.io.FilterInputStream.read()I > ... > > -- > Kjetil ?ster?s > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kjetil ?ster?s From tjarvi at qbang.org Fri Sep 4 06:00:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Sep 2009 06:00:40 -0600 (MDT) Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x7d0d] > J gnu.io.RXTXPort.nativeDrain(Z)Z > J gnu.io.RXTXPort$SerialOutputStream.flush()V > Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x9c55] > C [rxtxSerial.dll+0xa05e] > J gnu.io.RXTXPort.readByte()I > J gnu.io.RXTXPort$SerialInputStream.read()I RXTX 2.1-7 has concurrency issues that will show upon multicore systems. These should be resolved in the 2.2 pre release. A user application could synchronize the read/write/open/close calls while using 2.1 to avoid the concurrency issue. The flush is probably following a write while the readByte is coming from read(byte b). The bugs existed in rxtx for a long time. I assume changes in the JVM and the presence of multicore systems exposed the issues. -- Trent Jarvi tjarvi at qbang.org From kjetilos at gmail.com Fri Sep 4 06:33:33 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 14:33:33 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <7a803d460909040533n1caf240y8168477a578bc45c@mail.gmail.com> Den 4. september 2009 14.00 skrev Trent Jarvi f?lgende: > > > On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > >> Hi >> >> We are using RXTX version 2.1.7 actively and lately we are having some >> issues with the RXTX library crashing. We are running a windows xp >> system with multiple COM ports where each COM port have a serial >> device connected. Lately we have increased the amount of signaling >> done over the COM ports and we are experiencing several odd crashes. I >> tried to search the mailinglist for something similar but was unable >> to find anything. At one time the RXTX crashed in the >> gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the >> gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack >> traces if someone is interested in having a look. Has anyone seen the >> same crashes? and does anyone know what can cause such crash? >> >> >> Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x7d0d] >> J ?gnu.io.RXTXPort.nativeDrain(Z)Z >> J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > >> Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x9c55] >> C ?[rxtxSerial.dll+0xa05e] >> J ?gnu.io.RXTXPort.readByte()I >> J ?gnu.io.RXTXPort$SerialInputStream.read()I > > > RXTX 2.1-7 has concurrency issues that will show upon multicore systems. > These should be resolved in the 2.2 pre release. ?A user application could > synchronize the read/write/open/close calls while using 2.1 to avoid the > concurrency issue. > > The flush is probably following a write while the readByte is coming from > read(byte b). > > The bugs existed in rxtx for a long time. ?I assume changes in the JVM and > the presence of multicore systems exposed the issues. > Ok, so we should look more into using a newer version of RXTX. The current version from the webpage is 2.2pre2, what is the stability status of this version. Is it good enough for use in a production environment? -- Kjetil ?ster?s From martinezrodolfo at gmail.com Fri Sep 4 13:39:57 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Fri, 4 Sep 2009 15:09:57 -0430 Subject: [Rxtx] Problem with data available event Message-ID: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Hello list members. I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a serial port USB adapter to communicate with an electronical inmunoassay analyzer. The program works porperly with one model of the analyzer series. It defines a protocol which every message sent should be replied with an ACK in order to continue with the communication. Now we are trying to communicate with another model of the same brand and series wich in theory should be much of the same of what was previously done. Unfortunately, that is not the case. The problem with this connection is that it never fires the Data Available serial port event. Is like if nothing was being received in the input stream. The following code always prints zero when the equipment should be transmitting. ----------------------- beginning of sample code ---------------------------------- SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", 10000); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); int len = 0; byte[] readBuffer = new byte[8]; while (true) { len = in.read(readBuffer); System.out.println(len); writer.writeACK(); // writing ACK to analyzer } ----------------------- end of sample code ------------------------------------------ We know that the analyzer is transmitting because HyperTerminal does shows the proper output. In fact, after running the above code and connecting via Hyperterminal all data is received in one block. Is like the data sent from the analyzer is being held somewhere in the way. Sniffing at the serial port, noticed that IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this helps to find what might be wrong or not, but here they are: On Hyperterminal: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 XonLimit:80 XoffLimit:200 On Java: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 XonLimit:0 XoffLimit:0 Thanks in advance for your help. Rodolfo M From ilkka at myller.com Sat Sep 5 04:36:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 5 Sep 2009 13:36:27 +0300 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <121198EE-65A4-463B-ACC7-29FFB9855B2C@myller.com> Hi Rodolfo, By default RXTX does not enable any flow control for the serial port. Please check what flow control you have active in HyperTerminal when you are able to receive data and then use the same flow control with RXTX serial port: serialPort.setFlowControlMode(int flowcontrol); Possible flowcontrol flags are (from SerialPort class) FLOWCONTROL_NONE FLOWCONTROL_RTSCTS_IN FLOWCONTROL_RTSCTS_OUT FLOWCONTROL_XONXOFF_IN FLOWCONTROL_XONXOFF_OUT For example, you can try enabling RTS/CTS hardware flow control. Note the bitwise OR operator ' | ': serialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Also if your device requires RTS/CTS flow control make sure you have fully connected serial cable (not just RX, TX, GND for example, but also RTS, CTS, DTR). One thing you might want to check is the state of DTR (Data Terminal Ready). Some devices wait for the DTR signal before they send any data. You can enable or disable DTR signal (high/low) with: serialPort.setDTR( boolean state ); -- I > Hello list members. > > I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a > serial port USB adapter to communicate with an electronical > inmunoassay analyzer. The program works porperly with one model of the > analyzer series. It defines a protocol which every message sent should > be replied with an ACK in order to continue with the communication. > Now we are trying to communicate with another model of the same brand > and series wich in theory should be much of the same of what was > previously done. Unfortunately, that is not the case. The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. > > ----------------------- beginning of sample code > ---------------------------------- > SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", > 10000); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > InputStream in = serialPort.getInputStream(); > OutputStream out = serialPort.getOutputStream(); > > int len = 0; > byte[] readBuffer = new byte[8]; > while (true) { > len = in.read(readBuffer); > System.out.println(len); > > writer.writeACK(); // writing ACK to analyzer > } > ----------------------- end of sample code > ------------------------------------------ > > We know that the analyzer is transmitting because HyperTerminal does > shows the proper output. In fact, after running the above code and > connecting via Hyperterminal all data is received in one block. Is > like the data sent from the analyzer is being held somewhere in the > way. Sniffing at the serial port, noticed that > IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this > helps to find what might be wrong or not, but here they are: > > On Hyperterminal: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 > XonLimit:80 XoffLimit:200 > > On Java: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 > XonLimit:0 XoffLimit:0 > > > Thanks in advance for your help. > Rodolfo M > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Tue Sep 1 02:38:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 1 Sep 2009 02:38:40 -0600 (MDT) Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks Ilkka The problem should be resolved (confirmed from two locations). I'll be trying to hunt down a Snow Leopard box tomorrow evening as well. On Tue, 1 Sep 2009, Ilkka Myller wrote: > Hi, > > CVS server is reachable, but when trying anonymous login it replies: > > " > Fatal error, aborting. > anonymous: no such system user > " > > It seems that the anonymous cvs account is not yet properly configured on the > new system. > > -- > I > >> On Mon, 31 Aug 2009, Trent Jarvi wrote: >> >> The server has been beemed to another location for those experiencing >> routing problems. >> >> in bash: >> >> export CVSROOT=:pserver:anonymous at qbang.org:2401/var/cvs/cvsroot >> cvs login (no passwd) >> cvs co -r commapi-0-0-1 rxtx-devel >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Tue Sep 1 03:05:59 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 12:05:59 +0300 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks, The new CVS server works well :) I can also confirm that latest CVS version builds properly with unmodified Snow Leopard (Mac OS X 10.6) system: Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 gcc version 4.2.1 (Apple Inc. build 5646) Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) --> Resulting JNI library (Universal Binary): i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = 9d15fc488b301da8bf65b2c9456a7bbb --> Resulting JAR: RXTXComm.jar / 60942 bytes MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 Atleast it builds.. and probably works too. I have not tested that yet. -- I Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > The problem should be resolved (confirmed from two locations). I'll > be trying to hunt down a Snow Leopard box tomorrow evening as well. From jimmy.lee at emotum.com Tue Sep 1 05:07:19 2009 From: jimmy.lee at emotum.com (Jimmy Lee [emotum]) Date: Tue, 1 Sep 2009 21:07:19 +1000 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: <112685a90909010407i6054acb5tc2b12196797bfaf1@mail.gmail.com> Could we access to the binaries? Please :) 2009/9/1 Ilkka Myller > Thanks, > > The new CVS server works well :) > > I can also confirm that latest CVS version builds properly with unmodified > Snow Leopard (Mac OS X 10.6) system: > > Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_I386 i386 > gcc version 4.2.1 (Apple Inc. build 5646) > Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) > > > --> Resulting JNI library (Universal Binary): > > i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes > > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 > librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc > > MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = > 9d15fc488b301da8bf65b2c9456a7bbb > > > --> Resulting JAR: > > RXTXComm.jar / 60942 bytes > > MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 > > > > Atleast it builds.. and probably works too. I have not tested that yet. > > -- > I > > Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > > The problem should be resolved (confirmed from two locations). I'll be >> trying to hunt down a Snow Leopard box tomorrow evening as well. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Tue Sep 1 06:21:28 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Tue, 1 Sep 2009 08:21:28 -0400 (EDT) Subject: [Rxtx] Snow Leopard binaries Message-ID: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> +1 for binaries - pretty please with sugar on top... -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com From fredm at alum.mit.edu Tue Sep 1 06:24:17 2009 From: fredm at alum.mit.edu (Fred G. Martin) Date: Tue, 1 Sep 2009 08:24:17 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> Message-ID: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> You can find one here: http://iharder.sourceforge.net/current/java/ Also, you need to add yourself (any rxtx user) to the uucp group. Niutils don't exist, but dscl is a replacement. There is info for using it here: http://aplawrence.com/MacOSX/directory_services.html Fred On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Tue Sep 1 07:03:37 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Tue, 1 Sep 2009 18:33:37 +0530 Subject: [Rxtx] Help for RXTX on mac Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time I am able to read the device but on second time, it hangs on COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then it was showing the PortInUseException, I replaced the RXTX library to 2.2Pre1 so it is showing this problem. Is this is a problem with RXTX on Mac? Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: From ilkka at myller.com Tue Sep 1 07:57:06 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 16:57:06 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:02:31 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:02:31 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:43:49 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:43:49 +0300 Subject: [Rxtx] Help for RXTX on mac In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE@myller.com> Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Arseneau at Sun.COM Tue Sep 1 08:51:32 2009 From: Eric.Arseneau at Sun.COM (Eric Arseneau) Date: Tue, 01 Sep 2009 07:51:32 -0700 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24@sun.com> Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 09:24:30 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 18:24:30 +0300 Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D@myller.com> Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Thu Sep 3 02:50:16 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Thu, 3 Sep 2009 10:50:16 +0200 Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s From Kapil_Gupta at hcl.in Thu Sep 3 06:52:21 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:22:21 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From Kapil_Gupta at hcl.in Thu Sep 3 07:15:19 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:45:19 +0530 Subject: [Rxtx] Rxtx Digest, Vol 25, Issue 3 In-Reply-To: References: Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C50BB@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi myller, I have attached the code with the mail. Please help me if I am doing something wrong in it. Thanks & Regards, Kapil Gupta -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of rxtx-request at qbang.org Sent: Thursday, September 03, 2009 4:15 PM To: rxtx at qbang.org Subject: Rxtx Digest, Vol 25, Issue 3 Send Rxtx mailing list submissions to rxtx at qbang.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qbang.org/mailman/listinfo/rxtx or, via email, send a message with subject or body 'help' to rxtx-request at qbang.org You can reach the person managing the list at rxtx-owner at qbang.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Rxtx digest..." Today's Topics: 1. Re: Snow Leopard binaries (Ilkka Myller) 2. Re: Snow Leopard binaries (Ilkka Myller) 3. Re: Help for RXTX on mac (Ilkka Myller) 4. Re: Snow Leopard binaries (Eric Arseneau) 5. Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters (Ilkka Myller) 6. RXTX multiple crashes (Kjetil ?ster?s) 7. RXTX 2.2Pre + MacMini+ Deadlock while second time port open (Kapil Gupta) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Sep 2009 16:57:06 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 1 Sep 2009 17:02:31 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <55EC133D-DC83-45A3-849C-02714904D580 at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 1 Sep 2009 17:43:49 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Help for RXTX on mac Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Tue, 01 Sep 2009 07:51:32 -0700 From: Eric Arseneau Cc: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24 at sun.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 1 Sep 2009 18:24:30 +0300 From: Ilkka Myller To: rxtx Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Thu, 3 Sep 2009 10:50:16 +0200 From: Kjetil ?ster?s To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s ------------------------------ Message: 7 Date: Thu, 3 Sep 2009 18:22:21 +0530 From: Kapil Gupta To: "rxtx at qbang.org" Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059 at NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset="us-ascii" Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: ------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx End of Rxtx Digest, Vol 25, Issue 3 *********************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From ilkka at myller.com Thu Sep 3 11:17:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 3 Sep 2009 20:17:27 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <4520677F-E8F0-46F5-B4AD-3AD3A7C2AED3@myller.com> Hi Kapil, The code is incomplete and I did not find anything I could to test/ debug with this. I also tried to find the actual serial port opening, but found only a call to missing method which creates the SerialPort object (?): serialPort = getSerialPortConnection( COMPort, this.readEvent.getDeviceName(), SerialCommConfig.DEVICE1[SerialCommConfig.TIMEOUT], SerialCommConfig.DEVICE1[SerialCommConfig.BAUDRATE], SerialCommConfig.DEVICE1[SerialCommConfig.DATABITS], SerialCommConfig.DEVICE1[SerialCommConfig.STOPBITS], SerialCommConfig.DEVICE1[SerialCommConfig.PARITY] ); The class SerialCommConfig is missing too. If this is a part of the actual code you are using, please note that you are not actually closing the serial port. The call to close() method is commented out: try { // serialPort.close(); } catch (Exception ex) { ex.printStackTrace(); } Re-opening of the serial port wont work if you haven't properly closed it first. -- I > > I am using RXTX on Macintosh to communicate to my device. First time > the device responds well but on second time, it hangs on > COMPort.open (name, timeout). > > I have attached the source code in a file. Please help me. > > Thanks & Best Regards, > Kapil -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorton at intellimec.com Thu Sep 3 11:37:55 2009 From: dmorton at intellimec.com (Daniel Morton) Date: Thu, 3 Sep 2009 13:37:55 -0400 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. (I haven't tried previous version though). Daniel Morton Java/J2EE Developer Tel +1 519.745.8887 x4331 Email dmorton at intellimec.com www.intellimec.com | www.iLane.com | www.drivesync.com Intelligent Mechatronic Systems Inc. 435 King Street North Waterloo, ON N2J 2Z5 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s Sent: Thursday, September 03, 2009 4:50 AM To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. From alexanderkiel at gmx.net Fri Sep 4 02:29:15 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 10:29:15 +0200 Subject: [Rxtx] Official Javadoc Location Message-ID: <1252052955.4025.80.camel@T61-KIEL> Hi List, I wasn't able to find an official location of RXTX Javadoc accessible over HTTP. Maybe someone can link me to it. If there is no such location, I would like to see one. I like to link from my own Javadoc to such a location. Thanks Alexander - e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:19:25 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:19:25 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> Message-ID: <1252055965.4025.84.camel@T61-KIEL> Hi Michael, thanks for the pointer. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 09:48 +0100, Michael Tandy wrote: > RxTx javadoc: http://users.frii.com/jarvi/rxtx/doc/index.html > Javax interface RxTx duplicates javadoc: > http://java.sun.com/products/javacomm/reference/api/index.html > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:22:14 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:22:14 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> Message-ID: <1252056134.4025.87.camel@T61-KIEL> Hi Eike, thanks, but I need a direct package pointer so that Javadoc will link the gnu.io packages automatically to the right location. Michael has pointed me to http://users.frii.com/jarvi/rxtx/doc/index.html which has the gnu.io packages. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 11:04 +0200, Eike Hinderk J?rrens wrote: > Hi Alexander, > it seems to me that RXTX is implementing this API: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Kind regards, > Eike > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kjetilos at gmail.com Fri Sep 4 03:43:41 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 11:43:41 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> Message-ID: <7a803d460909040243ke4449ecucbe2cd8b15761746@mail.gmail.com> Hi Daniel, This is interesting, what type of application are you making? Is there a lot of signaling on different COM ports at the same time in your application? In our application we have 11 devices connected to different COM ports, 9 of these are in active use when the application is running. I'm wondering how to use the RXTX library version 2.1.7 in this scenario without causing it to crash. After adding more signaling on the COM ports in our application we have now experienced other crashes and it is natural to think that it has something to do with our way of using RXTX from several threads at the same time. So my question is are there any methods like read/write/flush/close that are not thread safe and should be handled with care? And similarly is the RXTXPort.SerialInputStream and RXTXPort.SerialOutputStream thread safe? 2009/9/3 Daniel Morton : > I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. ?(I haven't tried previous version though). > > Daniel Morton > Java/J2EE Developer > > Tel ? ?+1 519.745.8887 x4331 > Email ? ?dmorton at intellimec.com > > > www.intellimec.com ?| ?www.iLane.com ?| ?www.drivesync.com > > > > Intelligent Mechatronic Systems Inc. > 435 King Street North Waterloo, ON N2J 2Z5 > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s > Sent: Thursday, September 03, 2009 4:50 AM > To: rxtx at qbang.org > Subject: [Rxtx] RXTX multiple crashes > > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x7d0d] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0ce75800): ?JavaThread "Y Worker" daemon > [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 > > Registers: > EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 > ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 > EIP=0x10007d0d, EFLAGS=0x00010202 > > Top of Stack: (sp=0x0d7ff6d8) > 0x0d7ff6d8: ? 0d7ff700 00000000 00000000 00000000 > 0x0d7ff6e8: ? 02a2eae8 00000123 00002958 0d7ff718 > 0x0d7ff6f8: ? 7c830887 7c90d28a 7c8664b5 00000e2c > 0x0d7ff708: ? 00002958 00000000 00000000 7c90cffa > 0x0d7ff718: ? 7c809bdb 00002958 0d7ff758 00000e40 > 0x0d7ff728: ? 00002958 02bd0468 0ce75800 080e4ee0 > 0x0d7ff738: ? 00000000 00000000 00000000 00000000 > 0x0d7ff748: ? 00000000 00000000 00000014 7c90d09a > > Instructions: (pc=0x10007d0d) > 0x10007cfd: ? 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 > 0x10007d0d: ? 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 > > > Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x7d0d] > J ?gnu.io.RXTXPort.nativeDrain(Z)Z > J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > ... > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x9c55] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0cddf400): ?JavaThread "XXX Worker" daemon > [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 > > Registers: > EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 > ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 > EIP=0x10009c55, EFLAGS=0x00010206 > > Top of Stack: (sp=0x0bb8f830) > 0x0bb8f830: ? 00000000 00000000 c0000005 00000000 > 0x0bb8f840: ? 00000000 00f1f0a5 00000002 00000000 > 0x0bb8f850: ? 003a0100 0001003f 0bb8fb20 0b9ff918 > 0x0bb8f860: ? 00000000 00000000 0bb8fb68 0bb8fb20 > 0x0bb8f870: ? 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 > 0x0bb8f880: ? 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 > 0x0bb8f890: ? 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 > 0x0bb8f8a0: ? 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 > > Instructions: (pc=0x10009c55) > 0x10009c45: ? 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff > 0x10009c55: ? 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 > > > Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x9c55] > C ?[rxtxSerial.dll+0xa05e] > J ?gnu.io.RXTXPort.readByte()I > J ?gnu.io.RXTXPort$SerialInputStream.read()I > J ?java.io.FilterInputStream.read()I > ... > > -- > Kjetil ?ster?s > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kjetil ?ster?s From tjarvi at qbang.org Fri Sep 4 06:00:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Sep 2009 06:00:40 -0600 (MDT) Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x7d0d] > J gnu.io.RXTXPort.nativeDrain(Z)Z > J gnu.io.RXTXPort$SerialOutputStream.flush()V > Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x9c55] > C [rxtxSerial.dll+0xa05e] > J gnu.io.RXTXPort.readByte()I > J gnu.io.RXTXPort$SerialInputStream.read()I RXTX 2.1-7 has concurrency issues that will show upon multicore systems. These should be resolved in the 2.2 pre release. A user application could synchronize the read/write/open/close calls while using 2.1 to avoid the concurrency issue. The flush is probably following a write while the readByte is coming from read(byte b). The bugs existed in rxtx for a long time. I assume changes in the JVM and the presence of multicore systems exposed the issues. -- Trent Jarvi tjarvi at qbang.org From kjetilos at gmail.com Fri Sep 4 06:33:33 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 14:33:33 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <7a803d460909040533n1caf240y8168477a578bc45c@mail.gmail.com> Den 4. september 2009 14.00 skrev Trent Jarvi f?lgende: > > > On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > >> Hi >> >> We are using RXTX version 2.1.7 actively and lately we are having some >> issues with the RXTX library crashing. We are running a windows xp >> system with multiple COM ports where each COM port have a serial >> device connected. Lately we have increased the amount of signaling >> done over the COM ports and we are experiencing several odd crashes. I >> tried to search the mailinglist for something similar but was unable >> to find anything. At one time the RXTX crashed in the >> gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the >> gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack >> traces if someone is interested in having a look. Has anyone seen the >> same crashes? and does anyone know what can cause such crash? >> >> >> Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x7d0d] >> J ?gnu.io.RXTXPort.nativeDrain(Z)Z >> J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > >> Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x9c55] >> C ?[rxtxSerial.dll+0xa05e] >> J ?gnu.io.RXTXPort.readByte()I >> J ?gnu.io.RXTXPort$SerialInputStream.read()I > > > RXTX 2.1-7 has concurrency issues that will show upon multicore systems. > These should be resolved in the 2.2 pre release. ?A user application could > synchronize the read/write/open/close calls while using 2.1 to avoid the > concurrency issue. > > The flush is probably following a write while the readByte is coming from > read(byte b). > > The bugs existed in rxtx for a long time. ?I assume changes in the JVM and > the presence of multicore systems exposed the issues. > Ok, so we should look more into using a newer version of RXTX. The current version from the webpage is 2.2pre2, what is the stability status of this version. Is it good enough for use in a production environment? -- Kjetil ?ster?s From martinezrodolfo at gmail.com Fri Sep 4 13:39:57 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Fri, 4 Sep 2009 15:09:57 -0430 Subject: [Rxtx] Problem with data available event Message-ID: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Hello list members. I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a serial port USB adapter to communicate with an electronical inmunoassay analyzer. The program works porperly with one model of the analyzer series. It defines a protocol which every message sent should be replied with an ACK in order to continue with the communication. Now we are trying to communicate with another model of the same brand and series wich in theory should be much of the same of what was previously done. Unfortunately, that is not the case. The problem with this connection is that it never fires the Data Available serial port event. Is like if nothing was being received in the input stream. The following code always prints zero when the equipment should be transmitting. ----------------------- beginning of sample code ---------------------------------- SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", 10000); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); int len = 0; byte[] readBuffer = new byte[8]; while (true) { len = in.read(readBuffer); System.out.println(len); writer.writeACK(); // writing ACK to analyzer } ----------------------- end of sample code ------------------------------------------ We know that the analyzer is transmitting because HyperTerminal does shows the proper output. In fact, after running the above code and connecting via Hyperterminal all data is received in one block. Is like the data sent from the analyzer is being held somewhere in the way. Sniffing at the serial port, noticed that IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this helps to find what might be wrong or not, but here they are: On Hyperterminal: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 XonLimit:80 XoffLimit:200 On Java: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 XonLimit:0 XoffLimit:0 Thanks in advance for your help. Rodolfo M From ilkka at myller.com Sat Sep 5 04:36:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 5 Sep 2009 13:36:27 +0300 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <121198EE-65A4-463B-ACC7-29FFB9855B2C@myller.com> Hi Rodolfo, By default RXTX does not enable any flow control for the serial port. Please check what flow control you have active in HyperTerminal when you are able to receive data and then use the same flow control with RXTX serial port: serialPort.setFlowControlMode(int flowcontrol); Possible flowcontrol flags are (from SerialPort class) FLOWCONTROL_NONE FLOWCONTROL_RTSCTS_IN FLOWCONTROL_RTSCTS_OUT FLOWCONTROL_XONXOFF_IN FLOWCONTROL_XONXOFF_OUT For example, you can try enabling RTS/CTS hardware flow control. Note the bitwise OR operator ' | ': serialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Also if your device requires RTS/CTS flow control make sure you have fully connected serial cable (not just RX, TX, GND for example, but also RTS, CTS, DTR). One thing you might want to check is the state of DTR (Data Terminal Ready). Some devices wait for the DTR signal before they send any data. You can enable or disable DTR signal (high/low) with: serialPort.setDTR( boolean state ); -- I > Hello list members. > > I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a > serial port USB adapter to communicate with an electronical > inmunoassay analyzer. The program works porperly with one model of the > analyzer series. It defines a protocol which every message sent should > be replied with an ACK in order to continue with the communication. > Now we are trying to communicate with another model of the same brand > and series wich in theory should be much of the same of what was > previously done. Unfortunately, that is not the case. The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. > > ----------------------- beginning of sample code > ---------------------------------- > SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", > 10000); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > InputStream in = serialPort.getInputStream(); > OutputStream out = serialPort.getOutputStream(); > > int len = 0; > byte[] readBuffer = new byte[8]; > while (true) { > len = in.read(readBuffer); > System.out.println(len); > > writer.writeACK(); // writing ACK to analyzer > } > ----------------------- end of sample code > ------------------------------------------ > > We know that the analyzer is transmitting because HyperTerminal does > shows the proper output. In fact, after running the above code and > connecting via Hyperterminal all data is received in one block. Is > like the data sent from the analyzer is being held somewhere in the > way. Sniffing at the serial port, noticed that > IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this > helps to find what might be wrong or not, but here they are: > > On Hyperterminal: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 > XonLimit:80 XoffLimit:200 > > On Java: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 > XonLimit:0 XoffLimit:0 > > > Thanks in advance for your help. > Rodolfo M > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.weber99 at gmx.net Sun Sep 6 15:51:12 2009 From: karl.weber99 at gmx.net (Karl Weber) Date: Sun, 6 Sep 2009 21:51:12 +0200 Subject: [Rxtx] Cannot create lock file Message-ID: <200909062151.12228.karl.weber99@gmx.net> Hi, I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an opensuse repository as well as from the homepage of the rxtx project. I have already added the user to the group uucp, however, it does not have any effect. What else do I have to do to make it work? (It does work with user root, though.) The error message is: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL Thanks in advance, Karl From tjarvi at qbang.org Sun Sep 6 15:51:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 6 Sep 2009 13:51:42 -0600 (MDT) Subject: [Rxtx] Cannot create lock file In-Reply-To: <200909062151.12228.karl.weber99@gmx.net> References: <200909062151.12228.karl.weber99@gmx.net> Message-ID: On Sun, 6 Sep 2009, Karl Weber wrote: > Hi, > > I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an > opensuse repository as well as from the homepage of the rxtx project. > > I have already added the user to the group uucp, however, it does not have > any effect. What else do I have to do to make it work? (It does work with > user root, though.) > > The error message is: > > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to > create lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > > Thanks in advance, Karl Look at the group that owns /var/lock with ls -ld /var/lock The following should work as a user when they are in the correct group: touch /var/lock/test && rm -f /var/lock/test -- Trent Jarvi tjarvi at qbang.org From Luca.Catoni at sysdat.it Mon Sep 7 08:32:42 2009 From: Luca.Catoni at sysdat.it (Luca Catoni) Date: Mon, 7 Sep 2009 14:32:42 +0200 Subject: [Rxtx] time-out implementation Message-ID: I need to implement a simple timer class to manage time-out in my RS-232 serial communication with a remote device using the rxtx library. The functions that the timer should have are start(), and reset() and start() method must throw an exception (TimeoutException) when it expires. I am not an expert in concurrent programming and I do not have much knowledge on threads. myTimer.setExpirationTime(myvalue); ? public void serialEvent(SerialPortEvent event) { if (event.getEventType() == SerialPortEvent.OUTPUT_BUFFER_EMPTY) { // transmission ? out.write(?); try{ myTimer.start(); }catch(TimeoutException te){ myTimer.reset(); ? } ? if (event.getEventType() == SerialPortEvent.DATA_AVAILABLE) { // receiving in.read(?); if (mycondition){ myTimer.stop();//ok, timer NOT expired myTimer.reset();//now I can call start() method again in //transmission to restart my timer when I //have to transmit next data } Can anyone help me to implement the class MyTimer? thanks in advance. -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Mon Sep 7 08:49:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Mon, 7 Sep 2009 18:19:24 +0530 Subject: [Rxtx] 2.2Pre + MacMini+ Deadlock while second time port Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E22FB6F@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, Please find the updated code (close call was commented by mistake). This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From tjarvi at qbang.org Tue Sep 1 02:38:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 1 Sep 2009 02:38:40 -0600 (MDT) Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks Ilkka The problem should be resolved (confirmed from two locations). I'll be trying to hunt down a Snow Leopard box tomorrow evening as well. On Tue, 1 Sep 2009, Ilkka Myller wrote: > Hi, > > CVS server is reachable, but when trying anonymous login it replies: > > " > Fatal error, aborting. > anonymous: no such system user > " > > It seems that the anonymous cvs account is not yet properly configured on the > new system. > > -- > I > >> On Mon, 31 Aug 2009, Trent Jarvi wrote: >> >> The server has been beemed to another location for those experiencing >> routing problems. >> >> in bash: >> >> export CVSROOT=:pserver:anonymous at qbang.org:2401/var/cvs/cvsroot >> cvs login (no passwd) >> cvs co -r commapi-0-0-1 rxtx-devel >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Tue Sep 1 03:05:59 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 12:05:59 +0300 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks, The new CVS server works well :) I can also confirm that latest CVS version builds properly with unmodified Snow Leopard (Mac OS X 10.6) system: Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 gcc version 4.2.1 (Apple Inc. build 5646) Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) --> Resulting JNI library (Universal Binary): i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = 9d15fc488b301da8bf65b2c9456a7bbb --> Resulting JAR: RXTXComm.jar / 60942 bytes MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 Atleast it builds.. and probably works too. I have not tested that yet. -- I Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > The problem should be resolved (confirmed from two locations). I'll > be trying to hunt down a Snow Leopard box tomorrow evening as well. From jimmy.lee at emotum.com Tue Sep 1 05:07:19 2009 From: jimmy.lee at emotum.com (Jimmy Lee [emotum]) Date: Tue, 1 Sep 2009 21:07:19 +1000 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: <112685a90909010407i6054acb5tc2b12196797bfaf1@mail.gmail.com> Could we access to the binaries? Please :) 2009/9/1 Ilkka Myller > Thanks, > > The new CVS server works well :) > > I can also confirm that latest CVS version builds properly with unmodified > Snow Leopard (Mac OS X 10.6) system: > > Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_I386 i386 > gcc version 4.2.1 (Apple Inc. build 5646) > Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) > > > --> Resulting JNI library (Universal Binary): > > i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes > > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 > librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc > > MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = > 9d15fc488b301da8bf65b2c9456a7bbb > > > --> Resulting JAR: > > RXTXComm.jar / 60942 bytes > > MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 > > > > Atleast it builds.. and probably works too. I have not tested that yet. > > -- > I > > Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > > The problem should be resolved (confirmed from two locations). I'll be >> trying to hunt down a Snow Leopard box tomorrow evening as well. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Tue Sep 1 06:21:28 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Tue, 1 Sep 2009 08:21:28 -0400 (EDT) Subject: [Rxtx] Snow Leopard binaries Message-ID: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> +1 for binaries - pretty please with sugar on top... -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com From fredm at alum.mit.edu Tue Sep 1 06:24:17 2009 From: fredm at alum.mit.edu (Fred G. Martin) Date: Tue, 1 Sep 2009 08:24:17 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> Message-ID: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> You can find one here: http://iharder.sourceforge.net/current/java/ Also, you need to add yourself (any rxtx user) to the uucp group. Niutils don't exist, but dscl is a replacement. There is info for using it here: http://aplawrence.com/MacOSX/directory_services.html Fred On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Tue Sep 1 07:03:37 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Tue, 1 Sep 2009 18:33:37 +0530 Subject: [Rxtx] Help for RXTX on mac Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time I am able to read the device but on second time, it hangs on COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then it was showing the PortInUseException, I replaced the RXTX library to 2.2Pre1 so it is showing this problem. Is this is a problem with RXTX on Mac? Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: From ilkka at myller.com Tue Sep 1 07:57:06 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 16:57:06 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:02:31 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:02:31 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:43:49 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:43:49 +0300 Subject: [Rxtx] Help for RXTX on mac In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE@myller.com> Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Arseneau at Sun.COM Tue Sep 1 08:51:32 2009 From: Eric.Arseneau at Sun.COM (Eric Arseneau) Date: Tue, 01 Sep 2009 07:51:32 -0700 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24@sun.com> Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 09:24:30 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 18:24:30 +0300 Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D@myller.com> Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Thu Sep 3 02:50:16 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Thu, 3 Sep 2009 10:50:16 +0200 Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s From Kapil_Gupta at hcl.in Thu Sep 3 06:52:21 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:22:21 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From Kapil_Gupta at hcl.in Thu Sep 3 07:15:19 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:45:19 +0530 Subject: [Rxtx] Rxtx Digest, Vol 25, Issue 3 In-Reply-To: References: Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C50BB@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi myller, I have attached the code with the mail. Please help me if I am doing something wrong in it. Thanks & Regards, Kapil Gupta -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of rxtx-request at qbang.org Sent: Thursday, September 03, 2009 4:15 PM To: rxtx at qbang.org Subject: Rxtx Digest, Vol 25, Issue 3 Send Rxtx mailing list submissions to rxtx at qbang.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qbang.org/mailman/listinfo/rxtx or, via email, send a message with subject or body 'help' to rxtx-request at qbang.org You can reach the person managing the list at rxtx-owner at qbang.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Rxtx digest..." Today's Topics: 1. Re: Snow Leopard binaries (Ilkka Myller) 2. Re: Snow Leopard binaries (Ilkka Myller) 3. Re: Help for RXTX on mac (Ilkka Myller) 4. Re: Snow Leopard binaries (Eric Arseneau) 5. Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters (Ilkka Myller) 6. RXTX multiple crashes (Kjetil ?ster?s) 7. RXTX 2.2Pre + MacMini+ Deadlock while second time port open (Kapil Gupta) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Sep 2009 16:57:06 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 1 Sep 2009 17:02:31 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <55EC133D-DC83-45A3-849C-02714904D580 at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 1 Sep 2009 17:43:49 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Help for RXTX on mac Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Tue, 01 Sep 2009 07:51:32 -0700 From: Eric Arseneau Cc: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24 at sun.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 1 Sep 2009 18:24:30 +0300 From: Ilkka Myller To: rxtx Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Thu, 3 Sep 2009 10:50:16 +0200 From: Kjetil ?ster?s To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s ------------------------------ Message: 7 Date: Thu, 3 Sep 2009 18:22:21 +0530 From: Kapil Gupta To: "rxtx at qbang.org" Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059 at NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset="us-ascii" Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: ------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx End of Rxtx Digest, Vol 25, Issue 3 *********************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From ilkka at myller.com Thu Sep 3 11:17:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 3 Sep 2009 20:17:27 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <4520677F-E8F0-46F5-B4AD-3AD3A7C2AED3@myller.com> Hi Kapil, The code is incomplete and I did not find anything I could to test/ debug with this. I also tried to find the actual serial port opening, but found only a call to missing method which creates the SerialPort object (?): serialPort = getSerialPortConnection( COMPort, this.readEvent.getDeviceName(), SerialCommConfig.DEVICE1[SerialCommConfig.TIMEOUT], SerialCommConfig.DEVICE1[SerialCommConfig.BAUDRATE], SerialCommConfig.DEVICE1[SerialCommConfig.DATABITS], SerialCommConfig.DEVICE1[SerialCommConfig.STOPBITS], SerialCommConfig.DEVICE1[SerialCommConfig.PARITY] ); The class SerialCommConfig is missing too. If this is a part of the actual code you are using, please note that you are not actually closing the serial port. The call to close() method is commented out: try { // serialPort.close(); } catch (Exception ex) { ex.printStackTrace(); } Re-opening of the serial port wont work if you haven't properly closed it first. -- I > > I am using RXTX on Macintosh to communicate to my device. First time > the device responds well but on second time, it hangs on > COMPort.open (name, timeout). > > I have attached the source code in a file. Please help me. > > Thanks & Best Regards, > Kapil -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorton at intellimec.com Thu Sep 3 11:37:55 2009 From: dmorton at intellimec.com (Daniel Morton) Date: Thu, 3 Sep 2009 13:37:55 -0400 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. (I haven't tried previous version though). Daniel Morton Java/J2EE Developer Tel +1 519.745.8887 x4331 Email dmorton at intellimec.com www.intellimec.com | www.iLane.com | www.drivesync.com Intelligent Mechatronic Systems Inc. 435 King Street North Waterloo, ON N2J 2Z5 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s Sent: Thursday, September 03, 2009 4:50 AM To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. From alexanderkiel at gmx.net Fri Sep 4 02:29:15 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 10:29:15 +0200 Subject: [Rxtx] Official Javadoc Location Message-ID: <1252052955.4025.80.camel@T61-KIEL> Hi List, I wasn't able to find an official location of RXTX Javadoc accessible over HTTP. Maybe someone can link me to it. If there is no such location, I would like to see one. I like to link from my own Javadoc to such a location. Thanks Alexander - e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:19:25 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:19:25 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> Message-ID: <1252055965.4025.84.camel@T61-KIEL> Hi Michael, thanks for the pointer. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 09:48 +0100, Michael Tandy wrote: > RxTx javadoc: http://users.frii.com/jarvi/rxtx/doc/index.html > Javax interface RxTx duplicates javadoc: > http://java.sun.com/products/javacomm/reference/api/index.html > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:22:14 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:22:14 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> Message-ID: <1252056134.4025.87.camel@T61-KIEL> Hi Eike, thanks, but I need a direct package pointer so that Javadoc will link the gnu.io packages automatically to the right location. Michael has pointed me to http://users.frii.com/jarvi/rxtx/doc/index.html which has the gnu.io packages. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 11:04 +0200, Eike Hinderk J?rrens wrote: > Hi Alexander, > it seems to me that RXTX is implementing this API: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Kind regards, > Eike > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kjetilos at gmail.com Fri Sep 4 03:43:41 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 11:43:41 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> Message-ID: <7a803d460909040243ke4449ecucbe2cd8b15761746@mail.gmail.com> Hi Daniel, This is interesting, what type of application are you making? Is there a lot of signaling on different COM ports at the same time in your application? In our application we have 11 devices connected to different COM ports, 9 of these are in active use when the application is running. I'm wondering how to use the RXTX library version 2.1.7 in this scenario without causing it to crash. After adding more signaling on the COM ports in our application we have now experienced other crashes and it is natural to think that it has something to do with our way of using RXTX from several threads at the same time. So my question is are there any methods like read/write/flush/close that are not thread safe and should be handled with care? And similarly is the RXTXPort.SerialInputStream and RXTXPort.SerialOutputStream thread safe? 2009/9/3 Daniel Morton : > I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. ?(I haven't tried previous version though). > > Daniel Morton > Java/J2EE Developer > > Tel ? ?+1 519.745.8887 x4331 > Email ? ?dmorton at intellimec.com > > > www.intellimec.com ?| ?www.iLane.com ?| ?www.drivesync.com > > > > Intelligent Mechatronic Systems Inc. > 435 King Street North Waterloo, ON N2J 2Z5 > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s > Sent: Thursday, September 03, 2009 4:50 AM > To: rxtx at qbang.org > Subject: [Rxtx] RXTX multiple crashes > > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x7d0d] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0ce75800): ?JavaThread "Y Worker" daemon > [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 > > Registers: > EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 > ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 > EIP=0x10007d0d, EFLAGS=0x00010202 > > Top of Stack: (sp=0x0d7ff6d8) > 0x0d7ff6d8: ? 0d7ff700 00000000 00000000 00000000 > 0x0d7ff6e8: ? 02a2eae8 00000123 00002958 0d7ff718 > 0x0d7ff6f8: ? 7c830887 7c90d28a 7c8664b5 00000e2c > 0x0d7ff708: ? 00002958 00000000 00000000 7c90cffa > 0x0d7ff718: ? 7c809bdb 00002958 0d7ff758 00000e40 > 0x0d7ff728: ? 00002958 02bd0468 0ce75800 080e4ee0 > 0x0d7ff738: ? 00000000 00000000 00000000 00000000 > 0x0d7ff748: ? 00000000 00000000 00000014 7c90d09a > > Instructions: (pc=0x10007d0d) > 0x10007cfd: ? 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 > 0x10007d0d: ? 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 > > > Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x7d0d] > J ?gnu.io.RXTXPort.nativeDrain(Z)Z > J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > ... > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x9c55] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0cddf400): ?JavaThread "XXX Worker" daemon > [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 > > Registers: > EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 > ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 > EIP=0x10009c55, EFLAGS=0x00010206 > > Top of Stack: (sp=0x0bb8f830) > 0x0bb8f830: ? 00000000 00000000 c0000005 00000000 > 0x0bb8f840: ? 00000000 00f1f0a5 00000002 00000000 > 0x0bb8f850: ? 003a0100 0001003f 0bb8fb20 0b9ff918 > 0x0bb8f860: ? 00000000 00000000 0bb8fb68 0bb8fb20 > 0x0bb8f870: ? 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 > 0x0bb8f880: ? 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 > 0x0bb8f890: ? 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 > 0x0bb8f8a0: ? 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 > > Instructions: (pc=0x10009c55) > 0x10009c45: ? 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff > 0x10009c55: ? 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 > > > Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x9c55] > C ?[rxtxSerial.dll+0xa05e] > J ?gnu.io.RXTXPort.readByte()I > J ?gnu.io.RXTXPort$SerialInputStream.read()I > J ?java.io.FilterInputStream.read()I > ... > > -- > Kjetil ?ster?s > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kjetil ?ster?s From tjarvi at qbang.org Fri Sep 4 06:00:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Sep 2009 06:00:40 -0600 (MDT) Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x7d0d] > J gnu.io.RXTXPort.nativeDrain(Z)Z > J gnu.io.RXTXPort$SerialOutputStream.flush()V > Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x9c55] > C [rxtxSerial.dll+0xa05e] > J gnu.io.RXTXPort.readByte()I > J gnu.io.RXTXPort$SerialInputStream.read()I RXTX 2.1-7 has concurrency issues that will show upon multicore systems. These should be resolved in the 2.2 pre release. A user application could synchronize the read/write/open/close calls while using 2.1 to avoid the concurrency issue. The flush is probably following a write while the readByte is coming from read(byte b). The bugs existed in rxtx for a long time. I assume changes in the JVM and the presence of multicore systems exposed the issues. -- Trent Jarvi tjarvi at qbang.org From kjetilos at gmail.com Fri Sep 4 06:33:33 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 14:33:33 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <7a803d460909040533n1caf240y8168477a578bc45c@mail.gmail.com> Den 4. september 2009 14.00 skrev Trent Jarvi f?lgende: > > > On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > >> Hi >> >> We are using RXTX version 2.1.7 actively and lately we are having some >> issues with the RXTX library crashing. We are running a windows xp >> system with multiple COM ports where each COM port have a serial >> device connected. Lately we have increased the amount of signaling >> done over the COM ports and we are experiencing several odd crashes. I >> tried to search the mailinglist for something similar but was unable >> to find anything. At one time the RXTX crashed in the >> gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the >> gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack >> traces if someone is interested in having a look. Has anyone seen the >> same crashes? and does anyone know what can cause such crash? >> >> >> Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x7d0d] >> J ?gnu.io.RXTXPort.nativeDrain(Z)Z >> J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > >> Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x9c55] >> C ?[rxtxSerial.dll+0xa05e] >> J ?gnu.io.RXTXPort.readByte()I >> J ?gnu.io.RXTXPort$SerialInputStream.read()I > > > RXTX 2.1-7 has concurrency issues that will show upon multicore systems. > These should be resolved in the 2.2 pre release. ?A user application could > synchronize the read/write/open/close calls while using 2.1 to avoid the > concurrency issue. > > The flush is probably following a write while the readByte is coming from > read(byte b). > > The bugs existed in rxtx for a long time. ?I assume changes in the JVM and > the presence of multicore systems exposed the issues. > Ok, so we should look more into using a newer version of RXTX. The current version from the webpage is 2.2pre2, what is the stability status of this version. Is it good enough for use in a production environment? -- Kjetil ?ster?s From martinezrodolfo at gmail.com Fri Sep 4 13:39:57 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Fri, 4 Sep 2009 15:09:57 -0430 Subject: [Rxtx] Problem with data available event Message-ID: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Hello list members. I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a serial port USB adapter to communicate with an electronical inmunoassay analyzer. The program works porperly with one model of the analyzer series. It defines a protocol which every message sent should be replied with an ACK in order to continue with the communication. Now we are trying to communicate with another model of the same brand and series wich in theory should be much of the same of what was previously done. Unfortunately, that is not the case. The problem with this connection is that it never fires the Data Available serial port event. Is like if nothing was being received in the input stream. The following code always prints zero when the equipment should be transmitting. ----------------------- beginning of sample code ---------------------------------- SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", 10000); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); int len = 0; byte[] readBuffer = new byte[8]; while (true) { len = in.read(readBuffer); System.out.println(len); writer.writeACK(); // writing ACK to analyzer } ----------------------- end of sample code ------------------------------------------ We know that the analyzer is transmitting because HyperTerminal does shows the proper output. In fact, after running the above code and connecting via Hyperterminal all data is received in one block. Is like the data sent from the analyzer is being held somewhere in the way. Sniffing at the serial port, noticed that IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this helps to find what might be wrong or not, but here they are: On Hyperterminal: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 XonLimit:80 XoffLimit:200 On Java: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 XonLimit:0 XoffLimit:0 Thanks in advance for your help. Rodolfo M From ilkka at myller.com Sat Sep 5 04:36:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 5 Sep 2009 13:36:27 +0300 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <121198EE-65A4-463B-ACC7-29FFB9855B2C@myller.com> Hi Rodolfo, By default RXTX does not enable any flow control for the serial port. Please check what flow control you have active in HyperTerminal when you are able to receive data and then use the same flow control with RXTX serial port: serialPort.setFlowControlMode(int flowcontrol); Possible flowcontrol flags are (from SerialPort class) FLOWCONTROL_NONE FLOWCONTROL_RTSCTS_IN FLOWCONTROL_RTSCTS_OUT FLOWCONTROL_XONXOFF_IN FLOWCONTROL_XONXOFF_OUT For example, you can try enabling RTS/CTS hardware flow control. Note the bitwise OR operator ' | ': serialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Also if your device requires RTS/CTS flow control make sure you have fully connected serial cable (not just RX, TX, GND for example, but also RTS, CTS, DTR). One thing you might want to check is the state of DTR (Data Terminal Ready). Some devices wait for the DTR signal before they send any data. You can enable or disable DTR signal (high/low) with: serialPort.setDTR( boolean state ); -- I > Hello list members. > > I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a > serial port USB adapter to communicate with an electronical > inmunoassay analyzer. The program works porperly with one model of the > analyzer series. It defines a protocol which every message sent should > be replied with an ACK in order to continue with the communication. > Now we are trying to communicate with another model of the same brand > and series wich in theory should be much of the same of what was > previously done. Unfortunately, that is not the case. The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. > > ----------------------- beginning of sample code > ---------------------------------- > SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", > 10000); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > InputStream in = serialPort.getInputStream(); > OutputStream out = serialPort.getOutputStream(); > > int len = 0; > byte[] readBuffer = new byte[8]; > while (true) { > len = in.read(readBuffer); > System.out.println(len); > > writer.writeACK(); // writing ACK to analyzer > } > ----------------------- end of sample code > ------------------------------------------ > > We know that the analyzer is transmitting because HyperTerminal does > shows the proper output. In fact, after running the above code and > connecting via Hyperterminal all data is received in one block. Is > like the data sent from the analyzer is being held somewhere in the > way. Sniffing at the serial port, noticed that > IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this > helps to find what might be wrong or not, but here they are: > > On Hyperterminal: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 > XonLimit:80 XoffLimit:200 > > On Java: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 > XonLimit:0 XoffLimit:0 > > > Thanks in advance for your help. > Rodolfo M > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.weber99 at gmx.net Sun Sep 6 13:51:12 2009 From: karl.weber99 at gmx.net (Karl Weber) Date: Sun, 6 Sep 2009 21:51:12 +0200 Subject: [Rxtx] Cannot create lock file Message-ID: <200909062151.12228.karl.weber99@gmx.net> Hi, I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an opensuse repository as well as from the homepage of the rxtx project. I have already added the user to the group uucp, however, it does not have any effect. What else do I have to do to make it work? (It does work with user root, though.) The error message is: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL Thanks in advance, Karl From tjarvi at qbang.org Sun Sep 6 13:51:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 6 Sep 2009 13:51:42 -0600 (MDT) Subject: [Rxtx] Cannot create lock file In-Reply-To: <200909062151.12228.karl.weber99@gmx.net> References: <200909062151.12228.karl.weber99@gmx.net> Message-ID: On Sun, 6 Sep 2009, Karl Weber wrote: > Hi, > > I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an > opensuse repository as well as from the homepage of the rxtx project. > > I have already added the user to the group uucp, however, it does not have > any effect. What else do I have to do to make it work? (It does work with > user root, though.) > > The error message is: > > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to > create lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > > Thanks in advance, Karl Look at the group that owns /var/lock with ls -ld /var/lock The following should work as a user when they are in the correct group: touch /var/lock/test && rm -f /var/lock/test -- Trent Jarvi tjarvi at qbang.org From Luca.Catoni at sysdat.it Mon Sep 7 06:32:42 2009 From: Luca.Catoni at sysdat.it (Luca Catoni) Date: Mon, 7 Sep 2009 14:32:42 +0200 Subject: [Rxtx] time-out implementation Message-ID: I need to implement a simple timer class to manage time-out in my RS-232 serial communication with a remote device using the rxtx library. The functions that the timer should have are start(), and reset() and start() method must throw an exception (TimeoutException) when it expires. I am not an expert in concurrent programming and I do not have much knowledge on threads. myTimer.setExpirationTime(myvalue); ? public void serialEvent(SerialPortEvent event) { if (event.getEventType() == SerialPortEvent.OUTPUT_BUFFER_EMPTY) { // transmission ? out.write(?); try{ myTimer.start(); }catch(TimeoutException te){ myTimer.reset(); ? } ? if (event.getEventType() == SerialPortEvent.DATA_AVAILABLE) { // receiving in.read(?); if (mycondition){ myTimer.stop();//ok, timer NOT expired myTimer.reset();//now I can call start() method again in //transmission to restart my timer when I //have to transmit next data } Can anyone help me to implement the class MyTimer? thanks in advance. -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Mon Sep 7 06:49:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Mon, 7 Sep 2009 18:19:24 +0530 Subject: [Rxtx] 2.2Pre + MacMini+ Deadlock while second time port Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E22FB6F@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, Please find the updated code (close call was commented by mistake). This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From michael.erskine at ketech.com Mon Sep 7 11:13:03 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 7 Sep 2009 16:13:03 +0100 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Rodolfo Mart?nez > Subject: [Rxtx] Problem with data available event > The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. Hi Rodolfo, The sample code you provided doesn't implement or register any event listeners. Regards, Michael Erskine. From martinezrodolfo at gmail.com Mon Sep 7 12:21:22 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Mon, 7 Sep 2009 11:51:22 -0430 Subject: [Rxtx] Problem with data available event In-Reply-To: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> Message-ID: <30eacee0909070921l7f285765ue2c661963183fd2b@mail.gmail.com> On Mon, Sep 7, 2009 at 10:43 AM, Michael Erskine wrote: > Hi Rodolfo, > The sample code you provided doesn't implement or register any event listeners. > > Regards, > Michael Erskine. Hi Michael, I didn't write the event listeners declaration on the sample code for simplicity, but I do implement them on my real code. I should have mentioned it on the sample code anyway... my bad. I haven't had access to the device I'm trying to connect, but tomorrow will. And hope that with the explanation of Ilkka Myller will succeed this time. Thanks for your attention. Rodolfo M From ajmas at sympatico.ca Mon Sep 7 18:58:13 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 7 Sep 2009 18:58:13 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" I noticed in the page you posted posted you indicated that you patched two files. Did you submit the changes to Jarvi, so they could be included in the main code branch? Andr? From tjarvi at qbang.org Mon Sep 7 18:57:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Sep 2009 16:57:53 -0600 (MDT) Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On Mon, 7 Sep 2009, Andre-John Mas wrote: > > On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > >> Sorry, my rudeness was not intentional (a typo). >> Lets try again.. ;) >> >> "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > I noticed in the page you posted posted you indicated that you patched two > files. Did you submit the changes to Jarvi, so they could be included in the > main code branch? > Hi Andr? Ilkka is working with us to get changes in. I'm not sure about those two patches which may already be in CVS. I'll let him answer that. I've given him write access to CVS and asked him to cc the list non whitespace changes when they are ready. Right now he is asking questions off the list regarding cleaning up the Mac and w32 build files. -- Trent Jarvi tjarvi at qbang.org From nsp25 at cornell.edu Mon Sep 7 23:17:45 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Mon, 7 Sep 2009 23:17:45 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: (Sorry if this is a double post, but I sent my original message without subscribing, and since this is an urgent problem, I thought I'd resend after subscribing to bypass the moderator limbo zone) Hi all, I've asked my question on StackOverflow already, so rather than copy-paste the question here, I'd like to redirect you there . Short version, I am no longer able to receive anything over RS-232 with RXTX, but other programs work fine. I'm definitely sending things, because when I connect with a different program, all the responses to the commands I sent via RXTX arrive all at once. Everything was fine in the spring, so what could have happened? Windows update? -Nate -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.j.tandy at warwick.ac.uk Tue Sep 8 03:30:48 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Tue, 8 Sep 2009 08:30:48 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> OK, so: 1. It worked in spring but has stopped doing so and 2. The data all arrives at once when you start hyperterminal. Is it possible you're using a different serial cable to connect to the device, compared to the one you were using in spring? If so, the issue might be hardware flow control - that is, your device might be buffering data because it can't transmit it until your computer sets 'DTR' or 'RTS' or something like that. One way of bypassing hardware flow control is by using cables which cross over certain wires so that the right signals are always being sent; it's possible your old cable had these connections but your current cable doesn't have them. If you can find the old cable, you could put it back in and see if that fixes things? 2009/9/8 Nathaniel S. Parsons : > (Sorry if this is a double post, but I sent my original message without > subscribing, and since this is an urgent problem, I thought I'd resend after > subscribing to bypass the moderator limbo zone) > > Hi all, > > I've asked my question on StackOverflow already, so rather than copy-paste > the question here, I'd like to redirect you there. > > Short version, I am no longer able to receive anything over RS-232 with > RXTX, but other programs work fine. I'm definitely sending things, because > when I connect with a different program, all the responses to the commands I > sent via RXTX arrive all at once. > > Everything was fine in the spring, so what could have happened? Windows > update? > > -Nate > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Tue Sep 8 03:50:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 8 Sep 2009 10:50:33 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <111FEC9A-26BA-435C-BABC-314C7E4F23E5@myller.com> Hi all, Patches applied to the 2.1.7 binaries distributed by Robert Harder (http://iharder.sourceforge.net/current/java/ ) are already in the 2.2. Actually in 2.2 the issue with integer types handling seems to be fixed even more extensively than that single patch to 2.1.7 originally did. And yes, Trent has granted me CVS commit access. Thank you. First thing I'm going to focus on is the code quality and clean up: unused variables, invalid pointer usage etc.. Most of this just causing compile warnings - some harmless and some have potential for causing runtime problems. Instead of just blindly committing new changes to CVS, I've been discussing with Trent about the way things have been done in the RXTX CVS before. (how to handle white space patches, what needs to be discussed with the list first, proper locations for new files/ directories/subprojects, "the way things are done in RXTX"). But patches are coming and bugs will be fixed. I hope everyone will continue to submit the bugs they discover to this mailing list. Most important thing is to provide enough info (code;) so that the issue can be duplicated and eventually fixed. -- I > > > On Mon, 7 Sep 2009, Andre-John Mas wrote: >> >> I noticed in the page you posted posted you indicated that you >> patched two files. Did you submit the changes to Jarvi, so they >> could be included in the main code branch? >> > > Ilkka is working with us to get changes in. I'm not sure about > those two patches which may already be in CVS. I'll let him answer > that. > > I've given him write access to CVS and asked him to cc the list non > whitespace changes when they are ready. Right now he is asking > questions off the list regarding cleaning up the Mac and w32 build > files. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Tue Sep 1 02:38:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 1 Sep 2009 02:38:40 -0600 (MDT) Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks Ilkka The problem should be resolved (confirmed from two locations). I'll be trying to hunt down a Snow Leopard box tomorrow evening as well. On Tue, 1 Sep 2009, Ilkka Myller wrote: > Hi, > > CVS server is reachable, but when trying anonymous login it replies: > > " > Fatal error, aborting. > anonymous: no such system user > " > > It seems that the anonymous cvs account is not yet properly configured on the > new system. > > -- > I > >> On Mon, 31 Aug 2009, Trent Jarvi wrote: >> >> The server has been beemed to another location for those experiencing >> routing problems. >> >> in bash: >> >> export CVSROOT=:pserver:anonymous at qbang.org:2401/var/cvs/cvsroot >> cvs login (no passwd) >> cvs co -r commapi-0-0-1 rxtx-devel >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Tue Sep 1 03:05:59 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 12:05:59 +0300 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks, The new CVS server works well :) I can also confirm that latest CVS version builds properly with unmodified Snow Leopard (Mac OS X 10.6) system: Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 gcc version 4.2.1 (Apple Inc. build 5646) Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) --> Resulting JNI library (Universal Binary): i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = 9d15fc488b301da8bf65b2c9456a7bbb --> Resulting JAR: RXTXComm.jar / 60942 bytes MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 Atleast it builds.. and probably works too. I have not tested that yet. -- I Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > The problem should be resolved (confirmed from two locations). I'll > be trying to hunt down a Snow Leopard box tomorrow evening as well. From jimmy.lee at emotum.com Tue Sep 1 05:07:19 2009 From: jimmy.lee at emotum.com (Jimmy Lee [emotum]) Date: Tue, 1 Sep 2009 21:07:19 +1000 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: <112685a90909010407i6054acb5tc2b12196797bfaf1@mail.gmail.com> Could we access to the binaries? Please :) 2009/9/1 Ilkka Myller > Thanks, > > The new CVS server works well :) > > I can also confirm that latest CVS version builds properly with unmodified > Snow Leopard (Mac OS X 10.6) system: > > Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_I386 i386 > gcc version 4.2.1 (Apple Inc. build 5646) > Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) > > > --> Resulting JNI library (Universal Binary): > > i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes > > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 > librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc > > MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = > 9d15fc488b301da8bf65b2c9456a7bbb > > > --> Resulting JAR: > > RXTXComm.jar / 60942 bytes > > MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 > > > > Atleast it builds.. and probably works too. I have not tested that yet. > > -- > I > > Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > > The problem should be resolved (confirmed from two locations). I'll be >> trying to hunt down a Snow Leopard box tomorrow evening as well. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Tue Sep 1 06:21:28 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Tue, 1 Sep 2009 08:21:28 -0400 (EDT) Subject: [Rxtx] Snow Leopard binaries Message-ID: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> +1 for binaries - pretty please with sugar on top... -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com From fredm at alum.mit.edu Tue Sep 1 06:24:17 2009 From: fredm at alum.mit.edu (Fred G. Martin) Date: Tue, 1 Sep 2009 08:24:17 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> Message-ID: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> You can find one here: http://iharder.sourceforge.net/current/java/ Also, you need to add yourself (any rxtx user) to the uucp group. Niutils don't exist, but dscl is a replacement. There is info for using it here: http://aplawrence.com/MacOSX/directory_services.html Fred On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Tue Sep 1 07:03:37 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Tue, 1 Sep 2009 18:33:37 +0530 Subject: [Rxtx] Help for RXTX on mac Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time I am able to read the device but on second time, it hangs on COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then it was showing the PortInUseException, I replaced the RXTX library to 2.2Pre1 so it is showing this problem. Is this is a problem with RXTX on Mac? Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: From ilkka at myller.com Tue Sep 1 07:57:06 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 16:57:06 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:02:31 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:02:31 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:43:49 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:43:49 +0300 Subject: [Rxtx] Help for RXTX on mac In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE@myller.com> Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Arseneau at Sun.COM Tue Sep 1 08:51:32 2009 From: Eric.Arseneau at Sun.COM (Eric Arseneau) Date: Tue, 01 Sep 2009 07:51:32 -0700 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24@sun.com> Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 09:24:30 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 18:24:30 +0300 Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D@myller.com> Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Thu Sep 3 02:50:16 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Thu, 3 Sep 2009 10:50:16 +0200 Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s From Kapil_Gupta at hcl.in Thu Sep 3 06:52:21 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:22:21 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From Kapil_Gupta at hcl.in Thu Sep 3 07:15:19 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:45:19 +0530 Subject: [Rxtx] Rxtx Digest, Vol 25, Issue 3 In-Reply-To: References: Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C50BB@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi myller, I have attached the code with the mail. Please help me if I am doing something wrong in it. Thanks & Regards, Kapil Gupta -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of rxtx-request at qbang.org Sent: Thursday, September 03, 2009 4:15 PM To: rxtx at qbang.org Subject: Rxtx Digest, Vol 25, Issue 3 Send Rxtx mailing list submissions to rxtx at qbang.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qbang.org/mailman/listinfo/rxtx or, via email, send a message with subject or body 'help' to rxtx-request at qbang.org You can reach the person managing the list at rxtx-owner at qbang.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Rxtx digest..." Today's Topics: 1. Re: Snow Leopard binaries (Ilkka Myller) 2. Re: Snow Leopard binaries (Ilkka Myller) 3. Re: Help for RXTX on mac (Ilkka Myller) 4. Re: Snow Leopard binaries (Eric Arseneau) 5. Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters (Ilkka Myller) 6. RXTX multiple crashes (Kjetil ?ster?s) 7. RXTX 2.2Pre + MacMini+ Deadlock while second time port open (Kapil Gupta) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Sep 2009 16:57:06 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 1 Sep 2009 17:02:31 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <55EC133D-DC83-45A3-849C-02714904D580 at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 1 Sep 2009 17:43:49 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Help for RXTX on mac Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Tue, 01 Sep 2009 07:51:32 -0700 From: Eric Arseneau Cc: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24 at sun.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 1 Sep 2009 18:24:30 +0300 From: Ilkka Myller To: rxtx Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Thu, 3 Sep 2009 10:50:16 +0200 From: Kjetil ?ster?s To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s ------------------------------ Message: 7 Date: Thu, 3 Sep 2009 18:22:21 +0530 From: Kapil Gupta To: "rxtx at qbang.org" Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059 at NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset="us-ascii" Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: ------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx End of Rxtx Digest, Vol 25, Issue 3 *********************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From ilkka at myller.com Thu Sep 3 11:17:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 3 Sep 2009 20:17:27 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <4520677F-E8F0-46F5-B4AD-3AD3A7C2AED3@myller.com> Hi Kapil, The code is incomplete and I did not find anything I could to test/ debug with this. I also tried to find the actual serial port opening, but found only a call to missing method which creates the SerialPort object (?): serialPort = getSerialPortConnection( COMPort, this.readEvent.getDeviceName(), SerialCommConfig.DEVICE1[SerialCommConfig.TIMEOUT], SerialCommConfig.DEVICE1[SerialCommConfig.BAUDRATE], SerialCommConfig.DEVICE1[SerialCommConfig.DATABITS], SerialCommConfig.DEVICE1[SerialCommConfig.STOPBITS], SerialCommConfig.DEVICE1[SerialCommConfig.PARITY] ); The class SerialCommConfig is missing too. If this is a part of the actual code you are using, please note that you are not actually closing the serial port. The call to close() method is commented out: try { // serialPort.close(); } catch (Exception ex) { ex.printStackTrace(); } Re-opening of the serial port wont work if you haven't properly closed it first. -- I > > I am using RXTX on Macintosh to communicate to my device. First time > the device responds well but on second time, it hangs on > COMPort.open (name, timeout). > > I have attached the source code in a file. Please help me. > > Thanks & Best Regards, > Kapil -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorton at intellimec.com Thu Sep 3 11:37:55 2009 From: dmorton at intellimec.com (Daniel Morton) Date: Thu, 3 Sep 2009 13:37:55 -0400 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. (I haven't tried previous version though). Daniel Morton Java/J2EE Developer Tel +1 519.745.8887 x4331 Email dmorton at intellimec.com www.intellimec.com | www.iLane.com | www.drivesync.com Intelligent Mechatronic Systems Inc. 435 King Street North Waterloo, ON N2J 2Z5 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s Sent: Thursday, September 03, 2009 4:50 AM To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. From alexanderkiel at gmx.net Fri Sep 4 02:29:15 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 10:29:15 +0200 Subject: [Rxtx] Official Javadoc Location Message-ID: <1252052955.4025.80.camel@T61-KIEL> Hi List, I wasn't able to find an official location of RXTX Javadoc accessible over HTTP. Maybe someone can link me to it. If there is no such location, I would like to see one. I like to link from my own Javadoc to such a location. Thanks Alexander - e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:19:25 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:19:25 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> Message-ID: <1252055965.4025.84.camel@T61-KIEL> Hi Michael, thanks for the pointer. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 09:48 +0100, Michael Tandy wrote: > RxTx javadoc: http://users.frii.com/jarvi/rxtx/doc/index.html > Javax interface RxTx duplicates javadoc: > http://java.sun.com/products/javacomm/reference/api/index.html > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:22:14 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:22:14 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> Message-ID: <1252056134.4025.87.camel@T61-KIEL> Hi Eike, thanks, but I need a direct package pointer so that Javadoc will link the gnu.io packages automatically to the right location. Michael has pointed me to http://users.frii.com/jarvi/rxtx/doc/index.html which has the gnu.io packages. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 11:04 +0200, Eike Hinderk J?rrens wrote: > Hi Alexander, > it seems to me that RXTX is implementing this API: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Kind regards, > Eike > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kjetilos at gmail.com Fri Sep 4 03:43:41 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 11:43:41 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> Message-ID: <7a803d460909040243ke4449ecucbe2cd8b15761746@mail.gmail.com> Hi Daniel, This is interesting, what type of application are you making? Is there a lot of signaling on different COM ports at the same time in your application? In our application we have 11 devices connected to different COM ports, 9 of these are in active use when the application is running. I'm wondering how to use the RXTX library version 2.1.7 in this scenario without causing it to crash. After adding more signaling on the COM ports in our application we have now experienced other crashes and it is natural to think that it has something to do with our way of using RXTX from several threads at the same time. So my question is are there any methods like read/write/flush/close that are not thread safe and should be handled with care? And similarly is the RXTXPort.SerialInputStream and RXTXPort.SerialOutputStream thread safe? 2009/9/3 Daniel Morton : > I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. ?(I haven't tried previous version though). > > Daniel Morton > Java/J2EE Developer > > Tel ? ?+1 519.745.8887 x4331 > Email ? ?dmorton at intellimec.com > > > www.intellimec.com ?| ?www.iLane.com ?| ?www.drivesync.com > > > > Intelligent Mechatronic Systems Inc. > 435 King Street North Waterloo, ON N2J 2Z5 > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s > Sent: Thursday, September 03, 2009 4:50 AM > To: rxtx at qbang.org > Subject: [Rxtx] RXTX multiple crashes > > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x7d0d] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0ce75800): ?JavaThread "Y Worker" daemon > [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 > > Registers: > EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 > ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 > EIP=0x10007d0d, EFLAGS=0x00010202 > > Top of Stack: (sp=0x0d7ff6d8) > 0x0d7ff6d8: ? 0d7ff700 00000000 00000000 00000000 > 0x0d7ff6e8: ? 02a2eae8 00000123 00002958 0d7ff718 > 0x0d7ff6f8: ? 7c830887 7c90d28a 7c8664b5 00000e2c > 0x0d7ff708: ? 00002958 00000000 00000000 7c90cffa > 0x0d7ff718: ? 7c809bdb 00002958 0d7ff758 00000e40 > 0x0d7ff728: ? 00002958 02bd0468 0ce75800 080e4ee0 > 0x0d7ff738: ? 00000000 00000000 00000000 00000000 > 0x0d7ff748: ? 00000000 00000000 00000014 7c90d09a > > Instructions: (pc=0x10007d0d) > 0x10007cfd: ? 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 > 0x10007d0d: ? 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 > > > Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x7d0d] > J ?gnu.io.RXTXPort.nativeDrain(Z)Z > J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > ... > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x9c55] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0cddf400): ?JavaThread "XXX Worker" daemon > [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 > > Registers: > EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 > ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 > EIP=0x10009c55, EFLAGS=0x00010206 > > Top of Stack: (sp=0x0bb8f830) > 0x0bb8f830: ? 00000000 00000000 c0000005 00000000 > 0x0bb8f840: ? 00000000 00f1f0a5 00000002 00000000 > 0x0bb8f850: ? 003a0100 0001003f 0bb8fb20 0b9ff918 > 0x0bb8f860: ? 00000000 00000000 0bb8fb68 0bb8fb20 > 0x0bb8f870: ? 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 > 0x0bb8f880: ? 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 > 0x0bb8f890: ? 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 > 0x0bb8f8a0: ? 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 > > Instructions: (pc=0x10009c55) > 0x10009c45: ? 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff > 0x10009c55: ? 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 > > > Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x9c55] > C ?[rxtxSerial.dll+0xa05e] > J ?gnu.io.RXTXPort.readByte()I > J ?gnu.io.RXTXPort$SerialInputStream.read()I > J ?java.io.FilterInputStream.read()I > ... > > -- > Kjetil ?ster?s > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kjetil ?ster?s From tjarvi at qbang.org Fri Sep 4 06:00:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Sep 2009 06:00:40 -0600 (MDT) Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x7d0d] > J gnu.io.RXTXPort.nativeDrain(Z)Z > J gnu.io.RXTXPort$SerialOutputStream.flush()V > Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x9c55] > C [rxtxSerial.dll+0xa05e] > J gnu.io.RXTXPort.readByte()I > J gnu.io.RXTXPort$SerialInputStream.read()I RXTX 2.1-7 has concurrency issues that will show upon multicore systems. These should be resolved in the 2.2 pre release. A user application could synchronize the read/write/open/close calls while using 2.1 to avoid the concurrency issue. The flush is probably following a write while the readByte is coming from read(byte b). The bugs existed in rxtx for a long time. I assume changes in the JVM and the presence of multicore systems exposed the issues. -- Trent Jarvi tjarvi at qbang.org From kjetilos at gmail.com Fri Sep 4 06:33:33 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 14:33:33 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <7a803d460909040533n1caf240y8168477a578bc45c@mail.gmail.com> Den 4. september 2009 14.00 skrev Trent Jarvi f?lgende: > > > On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > >> Hi >> >> We are using RXTX version 2.1.7 actively and lately we are having some >> issues with the RXTX library crashing. We are running a windows xp >> system with multiple COM ports where each COM port have a serial >> device connected. Lately we have increased the amount of signaling >> done over the COM ports and we are experiencing several odd crashes. I >> tried to search the mailinglist for something similar but was unable >> to find anything. At one time the RXTX crashed in the >> gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the >> gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack >> traces if someone is interested in having a look. Has anyone seen the >> same crashes? and does anyone know what can cause such crash? >> >> >> Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x7d0d] >> J ?gnu.io.RXTXPort.nativeDrain(Z)Z >> J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > >> Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x9c55] >> C ?[rxtxSerial.dll+0xa05e] >> J ?gnu.io.RXTXPort.readByte()I >> J ?gnu.io.RXTXPort$SerialInputStream.read()I > > > RXTX 2.1-7 has concurrency issues that will show upon multicore systems. > These should be resolved in the 2.2 pre release. ?A user application could > synchronize the read/write/open/close calls while using 2.1 to avoid the > concurrency issue. > > The flush is probably following a write while the readByte is coming from > read(byte b). > > The bugs existed in rxtx for a long time. ?I assume changes in the JVM and > the presence of multicore systems exposed the issues. > Ok, so we should look more into using a newer version of RXTX. The current version from the webpage is 2.2pre2, what is the stability status of this version. Is it good enough for use in a production environment? -- Kjetil ?ster?s From martinezrodolfo at gmail.com Fri Sep 4 13:39:57 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Fri, 4 Sep 2009 15:09:57 -0430 Subject: [Rxtx] Problem with data available event Message-ID: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Hello list members. I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a serial port USB adapter to communicate with an electronical inmunoassay analyzer. The program works porperly with one model of the analyzer series. It defines a protocol which every message sent should be replied with an ACK in order to continue with the communication. Now we are trying to communicate with another model of the same brand and series wich in theory should be much of the same of what was previously done. Unfortunately, that is not the case. The problem with this connection is that it never fires the Data Available serial port event. Is like if nothing was being received in the input stream. The following code always prints zero when the equipment should be transmitting. ----------------------- beginning of sample code ---------------------------------- SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", 10000); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); int len = 0; byte[] readBuffer = new byte[8]; while (true) { len = in.read(readBuffer); System.out.println(len); writer.writeACK(); // writing ACK to analyzer } ----------------------- end of sample code ------------------------------------------ We know that the analyzer is transmitting because HyperTerminal does shows the proper output. In fact, after running the above code and connecting via Hyperterminal all data is received in one block. Is like the data sent from the analyzer is being held somewhere in the way. Sniffing at the serial port, noticed that IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this helps to find what might be wrong or not, but here they are: On Hyperterminal: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 XonLimit:80 XoffLimit:200 On Java: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 XonLimit:0 XoffLimit:0 Thanks in advance for your help. Rodolfo M From ilkka at myller.com Sat Sep 5 04:36:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 5 Sep 2009 13:36:27 +0300 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <121198EE-65A4-463B-ACC7-29FFB9855B2C@myller.com> Hi Rodolfo, By default RXTX does not enable any flow control for the serial port. Please check what flow control you have active in HyperTerminal when you are able to receive data and then use the same flow control with RXTX serial port: serialPort.setFlowControlMode(int flowcontrol); Possible flowcontrol flags are (from SerialPort class) FLOWCONTROL_NONE FLOWCONTROL_RTSCTS_IN FLOWCONTROL_RTSCTS_OUT FLOWCONTROL_XONXOFF_IN FLOWCONTROL_XONXOFF_OUT For example, you can try enabling RTS/CTS hardware flow control. Note the bitwise OR operator ' | ': serialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Also if your device requires RTS/CTS flow control make sure you have fully connected serial cable (not just RX, TX, GND for example, but also RTS, CTS, DTR). One thing you might want to check is the state of DTR (Data Terminal Ready). Some devices wait for the DTR signal before they send any data. You can enable or disable DTR signal (high/low) with: serialPort.setDTR( boolean state ); -- I > Hello list members. > > I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a > serial port USB adapter to communicate with an electronical > inmunoassay analyzer. The program works porperly with one model of the > analyzer series. It defines a protocol which every message sent should > be replied with an ACK in order to continue with the communication. > Now we are trying to communicate with another model of the same brand > and series wich in theory should be much of the same of what was > previously done. Unfortunately, that is not the case. The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. > > ----------------------- beginning of sample code > ---------------------------------- > SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", > 10000); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > InputStream in = serialPort.getInputStream(); > OutputStream out = serialPort.getOutputStream(); > > int len = 0; > byte[] readBuffer = new byte[8]; > while (true) { > len = in.read(readBuffer); > System.out.println(len); > > writer.writeACK(); // writing ACK to analyzer > } > ----------------------- end of sample code > ------------------------------------------ > > We know that the analyzer is transmitting because HyperTerminal does > shows the proper output. In fact, after running the above code and > connecting via Hyperterminal all data is received in one block. Is > like the data sent from the analyzer is being held somewhere in the > way. Sniffing at the serial port, noticed that > IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this > helps to find what might be wrong or not, but here they are: > > On Hyperterminal: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 > XonLimit:80 XoffLimit:200 > > On Java: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 > XonLimit:0 XoffLimit:0 > > > Thanks in advance for your help. > Rodolfo M > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.weber99 at gmx.net Sun Sep 6 13:51:12 2009 From: karl.weber99 at gmx.net (Karl Weber) Date: Sun, 6 Sep 2009 21:51:12 +0200 Subject: [Rxtx] Cannot create lock file Message-ID: <200909062151.12228.karl.weber99@gmx.net> Hi, I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an opensuse repository as well as from the homepage of the rxtx project. I have already added the user to the group uucp, however, it does not have any effect. What else do I have to do to make it work? (It does work with user root, though.) The error message is: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL Thanks in advance, Karl From tjarvi at qbang.org Sun Sep 6 13:51:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 6 Sep 2009 13:51:42 -0600 (MDT) Subject: [Rxtx] Cannot create lock file In-Reply-To: <200909062151.12228.karl.weber99@gmx.net> References: <200909062151.12228.karl.weber99@gmx.net> Message-ID: On Sun, 6 Sep 2009, Karl Weber wrote: > Hi, > > I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an > opensuse repository as well as from the homepage of the rxtx project. > > I have already added the user to the group uucp, however, it does not have > any effect. What else do I have to do to make it work? (It does work with > user root, though.) > > The error message is: > > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to > create lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > > Thanks in advance, Karl Look at the group that owns /var/lock with ls -ld /var/lock The following should work as a user when they are in the correct group: touch /var/lock/test && rm -f /var/lock/test -- Trent Jarvi tjarvi at qbang.org From Luca.Catoni at sysdat.it Mon Sep 7 06:32:42 2009 From: Luca.Catoni at sysdat.it (Luca Catoni) Date: Mon, 7 Sep 2009 14:32:42 +0200 Subject: [Rxtx] time-out implementation Message-ID: I need to implement a simple timer class to manage time-out in my RS-232 serial communication with a remote device using the rxtx library. The functions that the timer should have are start(), and reset() and start() method must throw an exception (TimeoutException) when it expires. I am not an expert in concurrent programming and I do not have much knowledge on threads. myTimer.setExpirationTime(myvalue); ? public void serialEvent(SerialPortEvent event) { if (event.getEventType() == SerialPortEvent.OUTPUT_BUFFER_EMPTY) { // transmission ? out.write(?); try{ myTimer.start(); }catch(TimeoutException te){ myTimer.reset(); ? } ? if (event.getEventType() == SerialPortEvent.DATA_AVAILABLE) { // receiving in.read(?); if (mycondition){ myTimer.stop();//ok, timer NOT expired myTimer.reset();//now I can call start() method again in //transmission to restart my timer when I //have to transmit next data } Can anyone help me to implement the class MyTimer? thanks in advance. -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Mon Sep 7 06:49:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Mon, 7 Sep 2009 18:19:24 +0530 Subject: [Rxtx] 2.2Pre + MacMini+ Deadlock while second time port Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E22FB6F@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, Please find the updated code (close call was commented by mistake). This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From michael.erskine at ketech.com Mon Sep 7 09:13:03 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 7 Sep 2009 16:13:03 +0100 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Rodolfo Mart?nez > Subject: [Rxtx] Problem with data available event > The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. Hi Rodolfo, The sample code you provided doesn't implement or register any event listeners. Regards, Michael Erskine. From martinezrodolfo at gmail.com Mon Sep 7 10:21:22 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Mon, 7 Sep 2009 11:51:22 -0430 Subject: [Rxtx] Problem with data available event In-Reply-To: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> Message-ID: <30eacee0909070921l7f285765ue2c661963183fd2b@mail.gmail.com> On Mon, Sep 7, 2009 at 10:43 AM, Michael Erskine wrote: > Hi Rodolfo, > The sample code you provided doesn't implement or register any event listeners. > > Regards, > Michael Erskine. Hi Michael, I didn't write the event listeners declaration on the sample code for simplicity, but I do implement them on my real code. I should have mentioned it on the sample code anyway... my bad. I haven't had access to the device I'm trying to connect, but tomorrow will. And hope that with the explanation of Ilkka Myller will succeed this time. Thanks for your attention. Rodolfo M From ajmas at sympatico.ca Mon Sep 7 16:58:13 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 7 Sep 2009 18:58:13 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" I noticed in the page you posted posted you indicated that you patched two files. Did you submit the changes to Jarvi, so they could be included in the main code branch? Andr? From tjarvi at qbang.org Mon Sep 7 16:57:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Sep 2009 16:57:53 -0600 (MDT) Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On Mon, 7 Sep 2009, Andre-John Mas wrote: > > On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > >> Sorry, my rudeness was not intentional (a typo). >> Lets try again.. ;) >> >> "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > I noticed in the page you posted posted you indicated that you patched two > files. Did you submit the changes to Jarvi, so they could be included in the > main code branch? > Hi Andr? Ilkka is working with us to get changes in. I'm not sure about those two patches which may already be in CVS. I'll let him answer that. I've given him write access to CVS and asked him to cc the list non whitespace changes when they are ready. Right now he is asking questions off the list regarding cleaning up the Mac and w32 build files. -- Trent Jarvi tjarvi at qbang.org From nsp25 at cornell.edu Mon Sep 7 21:17:45 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Mon, 7 Sep 2009 23:17:45 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: (Sorry if this is a double post, but I sent my original message without subscribing, and since this is an urgent problem, I thought I'd resend after subscribing to bypass the moderator limbo zone) Hi all, I've asked my question on StackOverflow already, so rather than copy-paste the question here, I'd like to redirect you there . Short version, I am no longer able to receive anything over RS-232 with RXTX, but other programs work fine. I'm definitely sending things, because when I connect with a different program, all the responses to the commands I sent via RXTX arrive all at once. Everything was fine in the spring, so what could have happened? Windows update? -Nate -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.j.tandy at warwick.ac.uk Tue Sep 8 01:30:48 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Tue, 8 Sep 2009 08:30:48 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> OK, so: 1. It worked in spring but has stopped doing so and 2. The data all arrives at once when you start hyperterminal. Is it possible you're using a different serial cable to connect to the device, compared to the one you were using in spring? If so, the issue might be hardware flow control - that is, your device might be buffering data because it can't transmit it until your computer sets 'DTR' or 'RTS' or something like that. One way of bypassing hardware flow control is by using cables which cross over certain wires so that the right signals are always being sent; it's possible your old cable had these connections but your current cable doesn't have them. If you can find the old cable, you could put it back in and see if that fixes things? 2009/9/8 Nathaniel S. Parsons : > (Sorry if this is a double post, but I sent my original message without > subscribing, and since this is an urgent problem, I thought I'd resend after > subscribing to bypass the moderator limbo zone) > > Hi all, > > I've asked my question on StackOverflow already, so rather than copy-paste > the question here, I'd like to redirect you there. > > Short version, I am no longer able to receive anything over RS-232 with > RXTX, but other programs work fine. I'm definitely sending things, because > when I connect with a different program, all the responses to the commands I > sent via RXTX arrive all at once. > > Everything was fine in the spring, so what could have happened? Windows > update? > > -Nate > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Tue Sep 8 01:50:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 8 Sep 2009 10:50:33 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <111FEC9A-26BA-435C-BABC-314C7E4F23E5@myller.com> Hi all, Patches applied to the 2.1.7 binaries distributed by Robert Harder (http://iharder.sourceforge.net/current/java/ ) are already in the 2.2. Actually in 2.2 the issue with integer types handling seems to be fixed even more extensively than that single patch to 2.1.7 originally did. And yes, Trent has granted me CVS commit access. Thank you. First thing I'm going to focus on is the code quality and clean up: unused variables, invalid pointer usage etc.. Most of this just causing compile warnings - some harmless and some have potential for causing runtime problems. Instead of just blindly committing new changes to CVS, I've been discussing with Trent about the way things have been done in the RXTX CVS before. (how to handle white space patches, what needs to be discussed with the list first, proper locations for new files/ directories/subprojects, "the way things are done in RXTX"). But patches are coming and bugs will be fixed. I hope everyone will continue to submit the bugs they discover to this mailing list. Most important thing is to provide enough info (code;) so that the issue can be duplicated and eventually fixed. -- I > > > On Mon, 7 Sep 2009, Andre-John Mas wrote: >> >> I noticed in the page you posted posted you indicated that you >> patched two files. Did you submit the changes to Jarvi, so they >> could be included in the main code branch? >> > > Ilkka is working with us to get changes in. I'm not sure about > those two patches which may already be in CVS. I'll let him answer > that. > > I've given him write access to CVS and asked him to cc the list non > whitespace changes when they are ready. Right now he is asking > questions off the list regarding cleaning up the Mac and w32 build > files. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 17:35:19 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 17:35:19 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: Thanks for the response. I'll try to get to the electronics store tomorrow to get more serial cables, even if it isn't the problem. I am using a different serial cable than I was in the spring. It's actually a Male/Female cable with a female-female adapter since the old cables aren't around anymore. The hardware's manual says nothing except to use a "Straight cable" but I figured that if it worked in HyperTerminal, it should work in RXTX, right? Anyways, I've also noticed some things that are different between HyperTerminal, RXTX, and a separate program I found that communicates with the device (but doesn't do what I want, which is why I'm rolling my own program) HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and DTR indicators are green Other program - not sure what settings it thinks it's using, but only SPM's RTS indicator is green RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators are on. From nsp25 at cornell.edu Tue Sep 8 20:57:58 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 20:57:58 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: I added a call to setRTS() but nothing changed in Serial Port Monitor, no matter what the argument was. Is this a bug, or did I call the wrong function? I tried to find the c code behind this function, and I think I found it in rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong to me. Am I looking at the right function or is the problem somewhere else? -Nate On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons wrote: > Thanks for the response. I'll try to get to the electronics store tomorrow > to get more serial cables, even if it isn't the problem. > > I am using a different serial cable than I was in the spring. It's actually > a Male/Female cable with a female-female adapter since the old cables aren't > around anymore. The hardware's manual says nothing except to use a "Straight > cable" but I figured that if it worked in HyperTerminal, it should work in > RXTX, right? > > Anyways, I've also noticed some things that are different between > HyperTerminal, RXTX, and a separate program I found that communicates with > the device (but doesn't do what I want, which is why I'm rolling my own > program) > > HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and > DTR indicators are green > Other program - not sure what settings it thinks it's using, but only SPM's > RTS indicator is green > RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators > are on. > > From Serial Port Monitor's help files (paraphrased): the indicators display > the state of the serial control lines > > RTS - Request To Send > CTS - Clear To Send > DTR - Data Terminal Ready > > Could this be related to the problem? > > -Nate > > > On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > >> OK, so: >> >> 1. It worked in spring but has stopped doing so and >> 2. The data all arrives at once when you start hyperterminal. >> >> Is it possible you're using a different serial cable to connect to the >> device, compared to the one you were using in spring? >> >> If so, the issue might be hardware flow control - that is, your device >> might be buffering data because it can't transmit it until your >> computer sets 'DTR' or 'RTS' or something like that. >> >> One way of bypassing hardware flow control is by using cables which >> cross over certain wires so that the right signals are always being >> sent; it's possible your old cable had these connections but your >> current cable doesn't have them. If you can find the old cable, you >> could put it back in and see if that fixes things? >> >> >> 2009/9/8 Nathaniel S. Parsons : >> > (Sorry if this is a double post, but I sent my original message without >> > subscribing, and since this is an urgent problem, I thought I'd resend >> after >> > subscribing to bypass the moderator limbo zone) >> > >> > Hi all, >> > >> > I've asked my question on StackOverflow already, so rather than >> copy-paste >> > the question here, I'd like to redirect you there. >> > >> > Short version, I am no longer able to receive anything over RS-232 with >> > RXTX, but other programs work fine. I'm definitely sending things, >> because >> > when I connect with a different program, all the responses to the >> commands I >> > sent via RXTX arrive all at once. >> > >> > Everything was fine in the spring, so what could have happened? Windows >> > update? >> > >> > -Nate >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Tue Sep 8 23:54:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 21:54:26 -0600 (MDT) Subject: [Rxtx] rxtx is moving to the clouds Message-ID: rxtx is moving onto a cloud server. You may notice short outages as things move around. So far the following is done. http://rxtx.qbang.org (will redirect rxtx.org there for 2.2) http://bugzilla.qbang.org (bugs) The mail-list is tomorrow night. CVS and FTP will be last. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Sep 9 00:03:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 22:03:26 -0600 (MDT) Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: On Tue, 8 Sep 2009, Nathaniel S. Parsons wrote: > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? Hi Nathaniel, That depends upon what you are running. WinCE is for embedded windows. The Windows source is in src/termios.c (called from src/SerialImp.c). -- Trent Jarvi tjarvi at qbang.org From m.j.tandy at warwick.ac.uk Wed Sep 9 05:27:10 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 10:27:10 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> I had a similar problem a while ago - hardware that would work with Hyperterminal but not with Rxtx. I don't know if this is a bug in RxTx or not - I tried to find where in the RxTx source code those functions are actually implemented - I got as far as the ioctl function in termios.c, where the TIOCMSET case sets the MSR byte in the termios struct, but I can't figure out where that gets written to the dcb struct's fDtrControl dword. It could be a bug, or it could just be me missing something. In any case, at the time I had this problem I wasn't equipped to debug RxTx so instead I created a special cable to satisfy the hardware's flow control while leaving the data connection straight through. Here's how I connected it: At the female end of the cable (i.e. the hardware I was connecting to) I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. I connected the ground and data pins straight through - that is, pin 5 female end to pin 5 male end, pin 2 female end to pin 2 male end, pin 3 female end to pin 3 male end. Anyway, using that cable bypassed the hardware's flow control, and got RxTx working just as well as HyperTerminal - although I slowed down my communication to make sure I didn't encounter a situation where the flow control would have come into effect, as I had bypassed it! Hope that helps. 2009/9/9 Nathaniel S. Parsons : > I added a call to setRTS() but nothing changed in Serial Port Monitor, no > matter what the argument was. Is this a bug, or did I call the wrong > function? > > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? > > -Nate > > On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > wrote: >> >> Thanks for the response. I'll try to get to the electronics store tomorrow >> to get more serial cables, even if it isn't the problem. >> >> I am using a different serial cable than I was in the spring. It's >> actually a Male/Female cable with a female-female adapter since the old >> cables aren't around anymore. The hardware's manual says nothing except to >> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >> should work in RXTX, right? >> >> Anyways, I've also noticed some things that are different between >> HyperTerminal, RXTX, and a separate program I found that communicates with >> the device (but doesn't do what I want, which is why I'm rolling my own >> program) >> >> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >> DTR indicators are green >> Other program - not sure what settings it thinks it's using, but only >> SPM's RTS indicator is green >> RXTX - no matter what flow control I set, only SPM's CTS and DTR >> indicators are on. >> >> From Serial Port Monitor's help files (paraphrased): the indicators >> display the state of the serial control lines >> >> RTS - Request To Send >> CTS - Clear To Send >> DTR - Data Terminal Ready >> >> Could this be related to the problem? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> wrote: >>> >>> OK, so: >>> >>> 1. It worked in spring but has stopped doing so and >>> 2. The data all arrives at once when you start hyperterminal. >>> >>> Is it possible you're using a different serial cable to connect to the >>> device, compared to the one you were using in spring? >>> >>> If so, the issue might be hardware flow control - that is, your device >>> might be buffering data because it can't transmit it until your >>> computer sets 'DTR' or 'RTS' or something like that. >>> >>> One way of bypassing hardware flow control is by using cables which >>> cross over certain wires so that the right signals are always being >>> sent; it's possible your old cable had these connections but your >>> current cable doesn't have them. If you can find the old cable, you >>> could put it back in and see if that fixes things? >>> >>> >>> 2009/9/8 Nathaniel S. Parsons : >>> > (Sorry if this is a double post, but I sent my original message without >>> > subscribing, and since this is an urgent problem, I thought I'd resend >>> > after >>> > subscribing to bypass the moderator limbo zone) >>> > >>> > Hi all, >>> > >>> > I've asked my question on StackOverflow already, so rather than >>> > copy-paste >>> > the question here, I'd like to redirect you there. >>> > >>> > Short version, I am no longer able to receive anything over RS-232 with >>> > RXTX, but other programs work fine. I'm definitely sending things, >>> > because >>> > when I connect with a different program, all the responses to the >>> > commands I >>> > sent via RXTX arrive all at once. >>> > >>> > Everything was fine in the spring, so what could have happened? Windows >>> > update? >>> > >>> > -Nate >>> > >>> > _______________________________________________ >>> > Rxtx mailing list >>> > Rxtx at qbang.org >>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>> > >>> > >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Wed Sep 9 05:54:45 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 12:54:45 +0300 Subject: [Rxtx] Xcode 3.x project available in CVS Message-ID: Hi everyone, I've just committed Apple Xcode 3.x (preferably 3.2) compatible project to CVS. The project can be used to develop and build Mac OS X 10.5+ compatible Universal Binary JNI library and RXTXcomm.jar. It's does not have dependencies to existing Autotools based build scripts - only standard Xcode installation is required. The older Xcode 2.x project is still there, but please note that it's not compatible with newer Xcode versions due to its dependency to deprecated Jam build system. The new project is available in rxtx-devel/MACOSX_IDE/Xcode3 How to get the source code from CVS: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Latest Xcode can be downloaded from Apple: http://developer.apple.com/technology/xcode.html -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 07:07:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 14:07:05 +0300 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: Nathaniel, I agree with Michael that your issue is probably with incorrect hardware flow control (RTS/CTS + possibly DTR/DSR). With RXTX you can do things manually, automatically or by mixing both ways. RXTX is "low-level" enough to let developer make those decisions. Which is proper. Automatic hardware flow-control: If you want to do automatic RTS/CTS flow control in both directions (from and to PC) you must set: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Note that you must combine flow control flags with bitwise OR ( ' | ' ) Manual: If you want to bypass all flow controls signals, or handle them manually you must set: setFlowControlMode( SerialPort.FLOWCONTROL_NONE ); In manual mode, you must manually handle controlling signals from PC and reading flow control signals from by the device: RTS - Request To Send -- setRTS() method can used to set this CTS - Clear To Send -- isCTS() method can be used to read this For example, it is entirely possible to manually implement normal RTS/ CTS flow control with RXTX without relying on low-level automatic implementation. Mixed: You can also configure serial port to handle RTS/CTS automatically in only one direction, then you must set one of: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN ); or setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_OUT ); Then you can either ignore or implement manually the flow control scheme in the other direction. DTR and DSR: These are not officially flow control signals, but might affect external devices (disable, standby etc.). Use and meaning of these depends on the device. DTR - Data Terminal Ready -- setDTR() method DSR - Data Set Ready -- setDSR() method CTS/RTS standards: Please note that there are two standard ways RTS/CTS flow control is done (depends on the device): asymmetric (RS-232) symmetric (RS-232-E / TIA-232-E) For more info see: http://en.wikipedia.org/wiki/RS232#RTS.2FCTS_handshaking Some devices may even use RTS/CTS to some other non-standard purpose. With those devices, enabling automatic RTS/CTS could cause very strange behaviour as they clearly require manual control of CTS/RTS. ---- As far as I know, RXTX properly controls all these signals all the way to actual RS232 pins - unless there is a new platform incompatibility bug that I'm not aware of;) Mostly it's just wrong combination and/or usage of these additional signals that cause problems receiving or sending. And the only solution is to really *know* how your device wants these signals handled - and then code your RXTX application accordingly. Creating non-standard cable is not the right solution in my opinion. Unfortunately some applications (like HyperTerminal for example) might hit more or less accidentally to the right combination of RTS/CTS/DTR/ DSR usage and make RXTX look bad in comparison. While all RXTX does by default is - well - nothing. It gives full control the developer. -- I > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port >> Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I >> found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't >> look wrong >> to me. Am I looking at the right function or is the problem >> somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > > >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store >>> tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since >>> the old >>> cables aren't around anymore. The hardware's manual says nothing >>> except to >>> use a "Straight cable" but I figured that if it worked in >>> HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that >>> communicates with >>> the device (but doesn't do what I want, which is why I'm rolling >>> my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's >>> RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but >>> only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> > >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect >>>> to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your >>>> device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>>> (Sorry if this is a double post, but I sent my original message >>>>> without >>>>> subscribing, and since this is an urgent problem, I thought I'd >>>>> resend >>>>> after >>>>> subscribing to bypass the moderator limbo zone) >>>>> >>>>> Hi all, >>>>> >>>>> I've asked my question on StackOverflow already, so rather than >>>>> copy-paste >>>>> the question here, I'd like to redirect you there. >>>>> >>>>> Short version, I am no longer able to receive anything over >>>>> RS-232 with >>>>> RXTX, but other programs work fine. I'm definitely sending things, >>>>> because >>>>> when I connect with a different program, all the responses to the >>>>> commands I >>>>> sent via RXTX arrive all at once. >>>>> >>>>> Everything was fine in the spring, so what could have happened? >>>>> Windows >>>>> update? >>>>> >>>>> -Nate >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 08:11:11 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 15:11:11 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings Message-ID: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Hi, Summary: Patch includes multiple minor code quality improvements and also fixes one possible null pointer segfault on Mac. After this patch, compilation on Mac OS X is error/warning free even with gcc -Wall setting. I'll submit more code quality patches later that focus more on linux/ win/java. Fixes: Code quality: - First level parentheses around assignment used as while-loop truth value - Some printf formats not a string literals and including no format arguments Invalid null pointer usage: - Mac: IOMasterPort was called with (int)NULL which does not always resolve to segfault safe value. Corrected to use MACH_PORT_NULL instead. Patch: The patch is against CVS head (@2009/09/09). Attached patch file is in 'cvs diff -up' format. I'll commit this patch to the CVS later this week if there are no objections. Feel free to comment. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090909.patch Type: application/octet-stream Size: 1966 bytes Desc: not available URL: From m.j.tandy at warwick.ac.uk Wed Sep 9 08:57:55 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 13:57:55 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> OK, I just ran a test with my copy of RxTx and the following program: import gnu.io.*; public class SerialTest { public static void main(String[] args) { try { CommPortIdentifier portid = CommPortIdentifier.getPortIdentifier("COM9"); SerialPort serialPort = (SerialPort)portid.open("Serial port DTR/RTS test", 1000); serialPort.setSerialPortParams(4800, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.disableReceiveTimeout(); for (int i=0 ; i<60 ; i++) { serialPort.setDTR(true); serialPort.setRTS(true); Thread.sleep(1000); serialPort.setDTR(false); serialPort.setRTS(false); Thread.sleep(1000); } } catch (Exception e) { e.printStackTrace(); System.exit(1); } System.exit(0); } } I'm using a USB-serial converter (Prolific PL-2303) and I used a multimeter to check that my DTR and RTS pins were both toggling, and they were - between +7 and -6.4 volts. In other words, on the computer I'm using at the moment, with the version of RxTx I'm using at the moment, setDTR and setRTS both seem to work fine. I don't know if it's worth it for you to perform the same test. I gather there are several different configurations for hardware flow control, (DTR/DSR handshaking as well as RTS/CTS handshaking, handshaking for half-duplex operation, and similar) so the cable that worked for me might still be worth a try. 2009/9/9 Michael Tandy : > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong >> to me. Am I looking at the right function or is the problem somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since the old >>> cables aren't around anymore. The hardware's manual says nothing except to >>> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that communicates with >>> the device (but doesn't do what I want, which is why I'm rolling my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>> > (Sorry if this is a double post, but I sent my original message without >>>> > subscribing, and since this is an urgent problem, I thought I'd resend >>>> > after >>>> > subscribing to bypass the moderator limbo zone) >>>> > >>>> > Hi all, >>>> > >>>> > I've asked my question on StackOverflow already, so rather than >>>> > copy-paste >>>> > the question here, I'd like to redirect you there. >>>> > >>>> > Short version, I am no longer able to receive anything over RS-232 with >>>> > RXTX, but other programs work fine. I'm definitely sending things, >>>> > because >>>> > when I connect with a different program, all the responses to the >>>> > commands I >>>> > sent via RXTX arrive all at once. >>>> > >>>> > Everything was fine in the spring, so what could have happened? Windows >>>> > update? >>>> > >>>> > -Nate >>>> > >>>> > _______________________________________________ >>>> > Rxtx mailing list >>>> > Rxtx at qbang.org >>>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>>> > >>>> > >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > From tjarvi at qbang.org Tue Sep 1 02:38:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 1 Sep 2009 02:38:40 -0600 (MDT) Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks Ilkka The problem should be resolved (confirmed from two locations). I'll be trying to hunt down a Snow Leopard box tomorrow evening as well. On Tue, 1 Sep 2009, Ilkka Myller wrote: > Hi, > > CVS server is reachable, but when trying anonymous login it replies: > > " > Fatal error, aborting. > anonymous: no such system user > " > > It seems that the anonymous cvs account is not yet properly configured on the > new system. > > -- > I > >> On Mon, 31 Aug 2009, Trent Jarvi wrote: >> >> The server has been beemed to another location for those experiencing >> routing problems. >> >> in bash: >> >> export CVSROOT=:pserver:anonymous at qbang.org:2401/var/cvs/cvsroot >> cvs login (no passwd) >> cvs co -r commapi-0-0-1 rxtx-devel >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Tue Sep 1 03:05:59 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 12:05:59 +0300 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks, The new CVS server works well :) I can also confirm that latest CVS version builds properly with unmodified Snow Leopard (Mac OS X 10.6) system: Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 gcc version 4.2.1 (Apple Inc. build 5646) Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) --> Resulting JNI library (Universal Binary): i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = 9d15fc488b301da8bf65b2c9456a7bbb --> Resulting JAR: RXTXComm.jar / 60942 bytes MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 Atleast it builds.. and probably works too. I have not tested that yet. -- I Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > The problem should be resolved (confirmed from two locations). I'll > be trying to hunt down a Snow Leopard box tomorrow evening as well. From jimmy.lee at emotum.com Tue Sep 1 05:07:19 2009 From: jimmy.lee at emotum.com (Jimmy Lee [emotum]) Date: Tue, 1 Sep 2009 21:07:19 +1000 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: <112685a90909010407i6054acb5tc2b12196797bfaf1@mail.gmail.com> Could we access to the binaries? Please :) 2009/9/1 Ilkka Myller > Thanks, > > The new CVS server works well :) > > I can also confirm that latest CVS version builds properly with unmodified > Snow Leopard (Mac OS X 10.6) system: > > Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_I386 i386 > gcc version 4.2.1 (Apple Inc. build 5646) > Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) > > > --> Resulting JNI library (Universal Binary): > > i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes > > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 > librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc > > MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = > 9d15fc488b301da8bf65b2c9456a7bbb > > > --> Resulting JAR: > > RXTXComm.jar / 60942 bytes > > MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 > > > > Atleast it builds.. and probably works too. I have not tested that yet. > > -- > I > > Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > > The problem should be resolved (confirmed from two locations). I'll be >> trying to hunt down a Snow Leopard box tomorrow evening as well. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Tue Sep 1 06:21:28 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Tue, 1 Sep 2009 08:21:28 -0400 (EDT) Subject: [Rxtx] Snow Leopard binaries Message-ID: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> +1 for binaries - pretty please with sugar on top... -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com From fredm at alum.mit.edu Tue Sep 1 06:24:17 2009 From: fredm at alum.mit.edu (Fred G. Martin) Date: Tue, 1 Sep 2009 08:24:17 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> Message-ID: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> You can find one here: http://iharder.sourceforge.net/current/java/ Also, you need to add yourself (any rxtx user) to the uucp group. Niutils don't exist, but dscl is a replacement. There is info for using it here: http://aplawrence.com/MacOSX/directory_services.html Fred On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Tue Sep 1 07:03:37 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Tue, 1 Sep 2009 18:33:37 +0530 Subject: [Rxtx] Help for RXTX on mac Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time I am able to read the device but on second time, it hangs on COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then it was showing the PortInUseException, I replaced the RXTX library to 2.2Pre1 so it is showing this problem. Is this is a problem with RXTX on Mac? Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: From ilkka at myller.com Tue Sep 1 07:57:06 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 16:57:06 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:02:31 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:02:31 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:43:49 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:43:49 +0300 Subject: [Rxtx] Help for RXTX on mac In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE@myller.com> Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Arseneau at Sun.COM Tue Sep 1 08:51:32 2009 From: Eric.Arseneau at Sun.COM (Eric Arseneau) Date: Tue, 01 Sep 2009 07:51:32 -0700 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24@sun.com> Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 09:24:30 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 18:24:30 +0300 Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D@myller.com> Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Thu Sep 3 02:50:16 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Thu, 3 Sep 2009 10:50:16 +0200 Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s From Kapil_Gupta at hcl.in Thu Sep 3 06:52:21 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:22:21 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From Kapil_Gupta at hcl.in Thu Sep 3 07:15:19 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:45:19 +0530 Subject: [Rxtx] Rxtx Digest, Vol 25, Issue 3 In-Reply-To: References: Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C50BB@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi myller, I have attached the code with the mail. Please help me if I am doing something wrong in it. Thanks & Regards, Kapil Gupta -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of rxtx-request at qbang.org Sent: Thursday, September 03, 2009 4:15 PM To: rxtx at qbang.org Subject: Rxtx Digest, Vol 25, Issue 3 Send Rxtx mailing list submissions to rxtx at qbang.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qbang.org/mailman/listinfo/rxtx or, via email, send a message with subject or body 'help' to rxtx-request at qbang.org You can reach the person managing the list at rxtx-owner at qbang.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Rxtx digest..." Today's Topics: 1. Re: Snow Leopard binaries (Ilkka Myller) 2. Re: Snow Leopard binaries (Ilkka Myller) 3. Re: Help for RXTX on mac (Ilkka Myller) 4. Re: Snow Leopard binaries (Eric Arseneau) 5. Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters (Ilkka Myller) 6. RXTX multiple crashes (Kjetil ?ster?s) 7. RXTX 2.2Pre + MacMini+ Deadlock while second time port open (Kapil Gupta) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Sep 2009 16:57:06 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 1 Sep 2009 17:02:31 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <55EC133D-DC83-45A3-849C-02714904D580 at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 1 Sep 2009 17:43:49 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Help for RXTX on mac Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Tue, 01 Sep 2009 07:51:32 -0700 From: Eric Arseneau Cc: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24 at sun.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 1 Sep 2009 18:24:30 +0300 From: Ilkka Myller To: rxtx Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Thu, 3 Sep 2009 10:50:16 +0200 From: Kjetil ?ster?s To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s ------------------------------ Message: 7 Date: Thu, 3 Sep 2009 18:22:21 +0530 From: Kapil Gupta To: "rxtx at qbang.org" Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059 at NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset="us-ascii" Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: ------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx End of Rxtx Digest, Vol 25, Issue 3 *********************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From ilkka at myller.com Thu Sep 3 11:17:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 3 Sep 2009 20:17:27 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <4520677F-E8F0-46F5-B4AD-3AD3A7C2AED3@myller.com> Hi Kapil, The code is incomplete and I did not find anything I could to test/ debug with this. I also tried to find the actual serial port opening, but found only a call to missing method which creates the SerialPort object (?): serialPort = getSerialPortConnection( COMPort, this.readEvent.getDeviceName(), SerialCommConfig.DEVICE1[SerialCommConfig.TIMEOUT], SerialCommConfig.DEVICE1[SerialCommConfig.BAUDRATE], SerialCommConfig.DEVICE1[SerialCommConfig.DATABITS], SerialCommConfig.DEVICE1[SerialCommConfig.STOPBITS], SerialCommConfig.DEVICE1[SerialCommConfig.PARITY] ); The class SerialCommConfig is missing too. If this is a part of the actual code you are using, please note that you are not actually closing the serial port. The call to close() method is commented out: try { // serialPort.close(); } catch (Exception ex) { ex.printStackTrace(); } Re-opening of the serial port wont work if you haven't properly closed it first. -- I > > I am using RXTX on Macintosh to communicate to my device. First time > the device responds well but on second time, it hangs on > COMPort.open (name, timeout). > > I have attached the source code in a file. Please help me. > > Thanks & Best Regards, > Kapil -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorton at intellimec.com Thu Sep 3 11:37:55 2009 From: dmorton at intellimec.com (Daniel Morton) Date: Thu, 3 Sep 2009 13:37:55 -0400 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. (I haven't tried previous version though). Daniel Morton Java/J2EE Developer Tel +1 519.745.8887 x4331 Email dmorton at intellimec.com www.intellimec.com | www.iLane.com | www.drivesync.com Intelligent Mechatronic Systems Inc. 435 King Street North Waterloo, ON N2J 2Z5 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s Sent: Thursday, September 03, 2009 4:50 AM To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. From alexanderkiel at gmx.net Fri Sep 4 02:29:15 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 10:29:15 +0200 Subject: [Rxtx] Official Javadoc Location Message-ID: <1252052955.4025.80.camel@T61-KIEL> Hi List, I wasn't able to find an official location of RXTX Javadoc accessible over HTTP. Maybe someone can link me to it. If there is no such location, I would like to see one. I like to link from my own Javadoc to such a location. Thanks Alexander - e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:19:25 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:19:25 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> Message-ID: <1252055965.4025.84.camel@T61-KIEL> Hi Michael, thanks for the pointer. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 09:48 +0100, Michael Tandy wrote: > RxTx javadoc: http://users.frii.com/jarvi/rxtx/doc/index.html > Javax interface RxTx duplicates javadoc: > http://java.sun.com/products/javacomm/reference/api/index.html > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:22:14 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:22:14 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> Message-ID: <1252056134.4025.87.camel@T61-KIEL> Hi Eike, thanks, but I need a direct package pointer so that Javadoc will link the gnu.io packages automatically to the right location. Michael has pointed me to http://users.frii.com/jarvi/rxtx/doc/index.html which has the gnu.io packages. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 11:04 +0200, Eike Hinderk J?rrens wrote: > Hi Alexander, > it seems to me that RXTX is implementing this API: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Kind regards, > Eike > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kjetilos at gmail.com Fri Sep 4 03:43:41 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 11:43:41 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> Message-ID: <7a803d460909040243ke4449ecucbe2cd8b15761746@mail.gmail.com> Hi Daniel, This is interesting, what type of application are you making? Is there a lot of signaling on different COM ports at the same time in your application? In our application we have 11 devices connected to different COM ports, 9 of these are in active use when the application is running. I'm wondering how to use the RXTX library version 2.1.7 in this scenario without causing it to crash. After adding more signaling on the COM ports in our application we have now experienced other crashes and it is natural to think that it has something to do with our way of using RXTX from several threads at the same time. So my question is are there any methods like read/write/flush/close that are not thread safe and should be handled with care? And similarly is the RXTXPort.SerialInputStream and RXTXPort.SerialOutputStream thread safe? 2009/9/3 Daniel Morton : > I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. ?(I haven't tried previous version though). > > Daniel Morton > Java/J2EE Developer > > Tel ? ?+1 519.745.8887 x4331 > Email ? ?dmorton at intellimec.com > > > www.intellimec.com ?| ?www.iLane.com ?| ?www.drivesync.com > > > > Intelligent Mechatronic Systems Inc. > 435 King Street North Waterloo, ON N2J 2Z5 > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s > Sent: Thursday, September 03, 2009 4:50 AM > To: rxtx at qbang.org > Subject: [Rxtx] RXTX multiple crashes > > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x7d0d] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0ce75800): ?JavaThread "Y Worker" daemon > [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 > > Registers: > EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 > ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 > EIP=0x10007d0d, EFLAGS=0x00010202 > > Top of Stack: (sp=0x0d7ff6d8) > 0x0d7ff6d8: ? 0d7ff700 00000000 00000000 00000000 > 0x0d7ff6e8: ? 02a2eae8 00000123 00002958 0d7ff718 > 0x0d7ff6f8: ? 7c830887 7c90d28a 7c8664b5 00000e2c > 0x0d7ff708: ? 00002958 00000000 00000000 7c90cffa > 0x0d7ff718: ? 7c809bdb 00002958 0d7ff758 00000e40 > 0x0d7ff728: ? 00002958 02bd0468 0ce75800 080e4ee0 > 0x0d7ff738: ? 00000000 00000000 00000000 00000000 > 0x0d7ff748: ? 00000000 00000000 00000014 7c90d09a > > Instructions: (pc=0x10007d0d) > 0x10007cfd: ? 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 > 0x10007d0d: ? 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 > > > Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x7d0d] > J ?gnu.io.RXTXPort.nativeDrain(Z)Z > J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > ... > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x9c55] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0cddf400): ?JavaThread "XXX Worker" daemon > [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 > > Registers: > EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 > ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 > EIP=0x10009c55, EFLAGS=0x00010206 > > Top of Stack: (sp=0x0bb8f830) > 0x0bb8f830: ? 00000000 00000000 c0000005 00000000 > 0x0bb8f840: ? 00000000 00f1f0a5 00000002 00000000 > 0x0bb8f850: ? 003a0100 0001003f 0bb8fb20 0b9ff918 > 0x0bb8f860: ? 00000000 00000000 0bb8fb68 0bb8fb20 > 0x0bb8f870: ? 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 > 0x0bb8f880: ? 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 > 0x0bb8f890: ? 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 > 0x0bb8f8a0: ? 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 > > Instructions: (pc=0x10009c55) > 0x10009c45: ? 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff > 0x10009c55: ? 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 > > > Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x9c55] > C ?[rxtxSerial.dll+0xa05e] > J ?gnu.io.RXTXPort.readByte()I > J ?gnu.io.RXTXPort$SerialInputStream.read()I > J ?java.io.FilterInputStream.read()I > ... > > -- > Kjetil ?ster?s > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kjetil ?ster?s From tjarvi at qbang.org Fri Sep 4 06:00:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Sep 2009 06:00:40 -0600 (MDT) Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x7d0d] > J gnu.io.RXTXPort.nativeDrain(Z)Z > J gnu.io.RXTXPort$SerialOutputStream.flush()V > Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x9c55] > C [rxtxSerial.dll+0xa05e] > J gnu.io.RXTXPort.readByte()I > J gnu.io.RXTXPort$SerialInputStream.read()I RXTX 2.1-7 has concurrency issues that will show upon multicore systems. These should be resolved in the 2.2 pre release. A user application could synchronize the read/write/open/close calls while using 2.1 to avoid the concurrency issue. The flush is probably following a write while the readByte is coming from read(byte b). The bugs existed in rxtx for a long time. I assume changes in the JVM and the presence of multicore systems exposed the issues. -- Trent Jarvi tjarvi at qbang.org From kjetilos at gmail.com Fri Sep 4 06:33:33 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 14:33:33 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <7a803d460909040533n1caf240y8168477a578bc45c@mail.gmail.com> Den 4. september 2009 14.00 skrev Trent Jarvi f?lgende: > > > On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > >> Hi >> >> We are using RXTX version 2.1.7 actively and lately we are having some >> issues with the RXTX library crashing. We are running a windows xp >> system with multiple COM ports where each COM port have a serial >> device connected. Lately we have increased the amount of signaling >> done over the COM ports and we are experiencing several odd crashes. I >> tried to search the mailinglist for something similar but was unable >> to find anything. At one time the RXTX crashed in the >> gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the >> gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack >> traces if someone is interested in having a look. Has anyone seen the >> same crashes? and does anyone know what can cause such crash? >> >> >> Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x7d0d] >> J ?gnu.io.RXTXPort.nativeDrain(Z)Z >> J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > >> Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x9c55] >> C ?[rxtxSerial.dll+0xa05e] >> J ?gnu.io.RXTXPort.readByte()I >> J ?gnu.io.RXTXPort$SerialInputStream.read()I > > > RXTX 2.1-7 has concurrency issues that will show upon multicore systems. > These should be resolved in the 2.2 pre release. ?A user application could > synchronize the read/write/open/close calls while using 2.1 to avoid the > concurrency issue. > > The flush is probably following a write while the readByte is coming from > read(byte b). > > The bugs existed in rxtx for a long time. ?I assume changes in the JVM and > the presence of multicore systems exposed the issues. > Ok, so we should look more into using a newer version of RXTX. The current version from the webpage is 2.2pre2, what is the stability status of this version. Is it good enough for use in a production environment? -- Kjetil ?ster?s From martinezrodolfo at gmail.com Fri Sep 4 13:39:57 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Fri, 4 Sep 2009 15:09:57 -0430 Subject: [Rxtx] Problem with data available event Message-ID: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Hello list members. I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a serial port USB adapter to communicate with an electronical inmunoassay analyzer. The program works porperly with one model of the analyzer series. It defines a protocol which every message sent should be replied with an ACK in order to continue with the communication. Now we are trying to communicate with another model of the same brand and series wich in theory should be much of the same of what was previously done. Unfortunately, that is not the case. The problem with this connection is that it never fires the Data Available serial port event. Is like if nothing was being received in the input stream. The following code always prints zero when the equipment should be transmitting. ----------------------- beginning of sample code ---------------------------------- SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", 10000); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); int len = 0; byte[] readBuffer = new byte[8]; while (true) { len = in.read(readBuffer); System.out.println(len); writer.writeACK(); // writing ACK to analyzer } ----------------------- end of sample code ------------------------------------------ We know that the analyzer is transmitting because HyperTerminal does shows the proper output. In fact, after running the above code and connecting via Hyperterminal all data is received in one block. Is like the data sent from the analyzer is being held somewhere in the way. Sniffing at the serial port, noticed that IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this helps to find what might be wrong or not, but here they are: On Hyperterminal: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 XonLimit:80 XoffLimit:200 On Java: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 XonLimit:0 XoffLimit:0 Thanks in advance for your help. Rodolfo M From ilkka at myller.com Sat Sep 5 04:36:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 5 Sep 2009 13:36:27 +0300 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <121198EE-65A4-463B-ACC7-29FFB9855B2C@myller.com> Hi Rodolfo, By default RXTX does not enable any flow control for the serial port. Please check what flow control you have active in HyperTerminal when you are able to receive data and then use the same flow control with RXTX serial port: serialPort.setFlowControlMode(int flowcontrol); Possible flowcontrol flags are (from SerialPort class) FLOWCONTROL_NONE FLOWCONTROL_RTSCTS_IN FLOWCONTROL_RTSCTS_OUT FLOWCONTROL_XONXOFF_IN FLOWCONTROL_XONXOFF_OUT For example, you can try enabling RTS/CTS hardware flow control. Note the bitwise OR operator ' | ': serialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Also if your device requires RTS/CTS flow control make sure you have fully connected serial cable (not just RX, TX, GND for example, but also RTS, CTS, DTR). One thing you might want to check is the state of DTR (Data Terminal Ready). Some devices wait for the DTR signal before they send any data. You can enable or disable DTR signal (high/low) with: serialPort.setDTR( boolean state ); -- I > Hello list members. > > I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a > serial port USB adapter to communicate with an electronical > inmunoassay analyzer. The program works porperly with one model of the > analyzer series. It defines a protocol which every message sent should > be replied with an ACK in order to continue with the communication. > Now we are trying to communicate with another model of the same brand > and series wich in theory should be much of the same of what was > previously done. Unfortunately, that is not the case. The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. > > ----------------------- beginning of sample code > ---------------------------------- > SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", > 10000); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > InputStream in = serialPort.getInputStream(); > OutputStream out = serialPort.getOutputStream(); > > int len = 0; > byte[] readBuffer = new byte[8]; > while (true) { > len = in.read(readBuffer); > System.out.println(len); > > writer.writeACK(); // writing ACK to analyzer > } > ----------------------- end of sample code > ------------------------------------------ > > We know that the analyzer is transmitting because HyperTerminal does > shows the proper output. In fact, after running the above code and > connecting via Hyperterminal all data is received in one block. Is > like the data sent from the analyzer is being held somewhere in the > way. Sniffing at the serial port, noticed that > IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this > helps to find what might be wrong or not, but here they are: > > On Hyperterminal: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 > XonLimit:80 XoffLimit:200 > > On Java: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 > XonLimit:0 XoffLimit:0 > > > Thanks in advance for your help. > Rodolfo M > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.weber99 at gmx.net Sun Sep 6 13:51:12 2009 From: karl.weber99 at gmx.net (Karl Weber) Date: Sun, 6 Sep 2009 21:51:12 +0200 Subject: [Rxtx] Cannot create lock file Message-ID: <200909062151.12228.karl.weber99@gmx.net> Hi, I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an opensuse repository as well as from the homepage of the rxtx project. I have already added the user to the group uucp, however, it does not have any effect. What else do I have to do to make it work? (It does work with user root, though.) The error message is: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL Thanks in advance, Karl From tjarvi at qbang.org Sun Sep 6 13:51:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 6 Sep 2009 13:51:42 -0600 (MDT) Subject: [Rxtx] Cannot create lock file In-Reply-To: <200909062151.12228.karl.weber99@gmx.net> References: <200909062151.12228.karl.weber99@gmx.net> Message-ID: On Sun, 6 Sep 2009, Karl Weber wrote: > Hi, > > I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an > opensuse repository as well as from the homepage of the rxtx project. > > I have already added the user to the group uucp, however, it does not have > any effect. What else do I have to do to make it work? (It does work with > user root, though.) > > The error message is: > > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to > create lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > > Thanks in advance, Karl Look at the group that owns /var/lock with ls -ld /var/lock The following should work as a user when they are in the correct group: touch /var/lock/test && rm -f /var/lock/test -- Trent Jarvi tjarvi at qbang.org From Luca.Catoni at sysdat.it Mon Sep 7 06:32:42 2009 From: Luca.Catoni at sysdat.it (Luca Catoni) Date: Mon, 7 Sep 2009 14:32:42 +0200 Subject: [Rxtx] time-out implementation Message-ID: I need to implement a simple timer class to manage time-out in my RS-232 serial communication with a remote device using the rxtx library. The functions that the timer should have are start(), and reset() and start() method must throw an exception (TimeoutException) when it expires. I am not an expert in concurrent programming and I do not have much knowledge on threads. myTimer.setExpirationTime(myvalue); ? public void serialEvent(SerialPortEvent event) { if (event.getEventType() == SerialPortEvent.OUTPUT_BUFFER_EMPTY) { // transmission ? out.write(?); try{ myTimer.start(); }catch(TimeoutException te){ myTimer.reset(); ? } ? if (event.getEventType() == SerialPortEvent.DATA_AVAILABLE) { // receiving in.read(?); if (mycondition){ myTimer.stop();//ok, timer NOT expired myTimer.reset();//now I can call start() method again in //transmission to restart my timer when I //have to transmit next data } Can anyone help me to implement the class MyTimer? thanks in advance. -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Mon Sep 7 06:49:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Mon, 7 Sep 2009 18:19:24 +0530 Subject: [Rxtx] 2.2Pre + MacMini+ Deadlock while second time port Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E22FB6F@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, Please find the updated code (close call was commented by mistake). This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From michael.erskine at ketech.com Mon Sep 7 09:13:03 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 7 Sep 2009 16:13:03 +0100 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Rodolfo Mart?nez > Subject: [Rxtx] Problem with data available event > The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. Hi Rodolfo, The sample code you provided doesn't implement or register any event listeners. Regards, Michael Erskine. From martinezrodolfo at gmail.com Mon Sep 7 10:21:22 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Mon, 7 Sep 2009 11:51:22 -0430 Subject: [Rxtx] Problem with data available event In-Reply-To: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> Message-ID: <30eacee0909070921l7f285765ue2c661963183fd2b@mail.gmail.com> On Mon, Sep 7, 2009 at 10:43 AM, Michael Erskine wrote: > Hi Rodolfo, > The sample code you provided doesn't implement or register any event listeners. > > Regards, > Michael Erskine. Hi Michael, I didn't write the event listeners declaration on the sample code for simplicity, but I do implement them on my real code. I should have mentioned it on the sample code anyway... my bad. I haven't had access to the device I'm trying to connect, but tomorrow will. And hope that with the explanation of Ilkka Myller will succeed this time. Thanks for your attention. Rodolfo M From ajmas at sympatico.ca Mon Sep 7 16:58:13 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 7 Sep 2009 18:58:13 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" I noticed in the page you posted posted you indicated that you patched two files. Did you submit the changes to Jarvi, so they could be included in the main code branch? Andr? From tjarvi at qbang.org Mon Sep 7 16:57:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Sep 2009 16:57:53 -0600 (MDT) Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On Mon, 7 Sep 2009, Andre-John Mas wrote: > > On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > >> Sorry, my rudeness was not intentional (a typo). >> Lets try again.. ;) >> >> "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > I noticed in the page you posted posted you indicated that you patched two > files. Did you submit the changes to Jarvi, so they could be included in the > main code branch? > Hi Andr? Ilkka is working with us to get changes in. I'm not sure about those two patches which may already be in CVS. I'll let him answer that. I've given him write access to CVS and asked him to cc the list non whitespace changes when they are ready. Right now he is asking questions off the list regarding cleaning up the Mac and w32 build files. -- Trent Jarvi tjarvi at qbang.org From nsp25 at cornell.edu Mon Sep 7 21:17:45 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Mon, 7 Sep 2009 23:17:45 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: (Sorry if this is a double post, but I sent my original message without subscribing, and since this is an urgent problem, I thought I'd resend after subscribing to bypass the moderator limbo zone) Hi all, I've asked my question on StackOverflow already, so rather than copy-paste the question here, I'd like to redirect you there . Short version, I am no longer able to receive anything over RS-232 with RXTX, but other programs work fine. I'm definitely sending things, because when I connect with a different program, all the responses to the commands I sent via RXTX arrive all at once. Everything was fine in the spring, so what could have happened? Windows update? -Nate -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.j.tandy at warwick.ac.uk Tue Sep 8 01:30:48 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Tue, 8 Sep 2009 08:30:48 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> OK, so: 1. It worked in spring but has stopped doing so and 2. The data all arrives at once when you start hyperterminal. Is it possible you're using a different serial cable to connect to the device, compared to the one you were using in spring? If so, the issue might be hardware flow control - that is, your device might be buffering data because it can't transmit it until your computer sets 'DTR' or 'RTS' or something like that. One way of bypassing hardware flow control is by using cables which cross over certain wires so that the right signals are always being sent; it's possible your old cable had these connections but your current cable doesn't have them. If you can find the old cable, you could put it back in and see if that fixes things? 2009/9/8 Nathaniel S. Parsons : > (Sorry if this is a double post, but I sent my original message without > subscribing, and since this is an urgent problem, I thought I'd resend after > subscribing to bypass the moderator limbo zone) > > Hi all, > > I've asked my question on StackOverflow already, so rather than copy-paste > the question here, I'd like to redirect you there. > > Short version, I am no longer able to receive anything over RS-232 with > RXTX, but other programs work fine. I'm definitely sending things, because > when I connect with a different program, all the responses to the commands I > sent via RXTX arrive all at once. > > Everything was fine in the spring, so what could have happened? Windows > update? > > -Nate > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Tue Sep 8 01:50:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 8 Sep 2009 10:50:33 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <111FEC9A-26BA-435C-BABC-314C7E4F23E5@myller.com> Hi all, Patches applied to the 2.1.7 binaries distributed by Robert Harder (http://iharder.sourceforge.net/current/java/ ) are already in the 2.2. Actually in 2.2 the issue with integer types handling seems to be fixed even more extensively than that single patch to 2.1.7 originally did. And yes, Trent has granted me CVS commit access. Thank you. First thing I'm going to focus on is the code quality and clean up: unused variables, invalid pointer usage etc.. Most of this just causing compile warnings - some harmless and some have potential for causing runtime problems. Instead of just blindly committing new changes to CVS, I've been discussing with Trent about the way things have been done in the RXTX CVS before. (how to handle white space patches, what needs to be discussed with the list first, proper locations for new files/ directories/subprojects, "the way things are done in RXTX"). But patches are coming and bugs will be fixed. I hope everyone will continue to submit the bugs they discover to this mailing list. Most important thing is to provide enough info (code;) so that the issue can be duplicated and eventually fixed. -- I > > > On Mon, 7 Sep 2009, Andre-John Mas wrote: >> >> I noticed in the page you posted posted you indicated that you >> patched two files. Did you submit the changes to Jarvi, so they >> could be included in the main code branch? >> > > Ilkka is working with us to get changes in. I'm not sure about > those two patches which may already be in CVS. I'll let him answer > that. > > I've given him write access to CVS and asked him to cc the list non > whitespace changes when they are ready. Right now he is asking > questions off the list regarding cleaning up the Mac and w32 build > files. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 15:35:19 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 17:35:19 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: Thanks for the response. I'll try to get to the electronics store tomorrow to get more serial cables, even if it isn't the problem. I am using a different serial cable than I was in the spring. It's actually a Male/Female cable with a female-female adapter since the old cables aren't around anymore. The hardware's manual says nothing except to use a "Straight cable" but I figured that if it worked in HyperTerminal, it should work in RXTX, right? Anyways, I've also noticed some things that are different between HyperTerminal, RXTX, and a separate program I found that communicates with the device (but doesn't do what I want, which is why I'm rolling my own program) HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and DTR indicators are green Other program - not sure what settings it thinks it's using, but only SPM's RTS indicator is green RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators are on. >From Serial Port Monitor's help files (paraphrased): the indicators display the state of the serial control lines RTS - Request To Send CTS - Clear To Send DTR - Data Terminal Ready Could this be related to the problem? -Nate On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > OK, so: > > 1. It worked in spring but has stopped doing so and > 2. The data all arrives at once when you start hyperterminal. > > Is it possible you're using a different serial cable to connect to the > device, compared to the one you were using in spring? > > If so, the issue might be hardware flow control - that is, your device > might be buffering data because it can't transmit it until your > computer sets 'DTR' or 'RTS' or something like that. > > One way of bypassing hardware flow control is by using cables which > cross over certain wires so that the right signals are always being > sent; it's possible your old cable had these connections but your > current cable doesn't have them. If you can find the old cable, you > could put it back in and see if that fixes things? > > > 2009/9/8 Nathaniel S. Parsons : > > (Sorry if this is a double post, but I sent my original message without > > subscribing, and since this is an urgent problem, I thought I'd resend > after > > subscribing to bypass the moderator limbo zone) > > > > Hi all, > > > > I've asked my question on StackOverflow already, so rather than > copy-paste > > the question here, I'd like to redirect you there. > > > > Short version, I am no longer able to receive anything over RS-232 with > > RXTX, but other programs work fine. I'm definitely sending things, > because > > when I connect with a different program, all the responses to the > commands I > > sent via RXTX arrive all at once. > > > > Everything was fine in the spring, so what could have happened? Windows > > update? > > > > -Nate > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 18:57:58 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 20:57:58 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: I added a call to setRTS() but nothing changed in Serial Port Monitor, no matter what the argument was. Is this a bug, or did I call the wrong function? I tried to find the c code behind this function, and I think I found it in rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong to me. Am I looking at the right function or is the problem somewhere else? -Nate On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons wrote: > Thanks for the response. I'll try to get to the electronics store tomorrow > to get more serial cables, even if it isn't the problem. > > I am using a different serial cable than I was in the spring. It's actually > a Male/Female cable with a female-female adapter since the old cables aren't > around anymore. The hardware's manual says nothing except to use a "Straight > cable" but I figured that if it worked in HyperTerminal, it should work in > RXTX, right? > > Anyways, I've also noticed some things that are different between > HyperTerminal, RXTX, and a separate program I found that communicates with > the device (but doesn't do what I want, which is why I'm rolling my own > program) > > HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and > DTR indicators are green > Other program - not sure what settings it thinks it's using, but only SPM's > RTS indicator is green > RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators > are on. > > From Serial Port Monitor's help files (paraphrased): the indicators display > the state of the serial control lines > > RTS - Request To Send > CTS - Clear To Send > DTR - Data Terminal Ready > > Could this be related to the problem? > > -Nate > > > On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > >> OK, so: >> >> 1. It worked in spring but has stopped doing so and >> 2. The data all arrives at once when you start hyperterminal. >> >> Is it possible you're using a different serial cable to connect to the >> device, compared to the one you were using in spring? >> >> If so, the issue might be hardware flow control - that is, your device >> might be buffering data because it can't transmit it until your >> computer sets 'DTR' or 'RTS' or something like that. >> >> One way of bypassing hardware flow control is by using cables which >> cross over certain wires so that the right signals are always being >> sent; it's possible your old cable had these connections but your >> current cable doesn't have them. If you can find the old cable, you >> could put it back in and see if that fixes things? >> >> >> 2009/9/8 Nathaniel S. Parsons : >> > (Sorry if this is a double post, but I sent my original message without >> > subscribing, and since this is an urgent problem, I thought I'd resend >> after >> > subscribing to bypass the moderator limbo zone) >> > >> > Hi all, >> > >> > I've asked my question on StackOverflow already, so rather than >> copy-paste >> > the question here, I'd like to redirect you there. >> > >> > Short version, I am no longer able to receive anything over RS-232 with >> > RXTX, but other programs work fine. I'm definitely sending things, >> because >> > when I connect with a different program, all the responses to the >> commands I >> > sent via RXTX arrive all at once. >> > >> > Everything was fine in the spring, so what could have happened? Windows >> > update? >> > >> > -Nate >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Tue Sep 8 21:54:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 21:54:26 -0600 (MDT) Subject: [Rxtx] rxtx is moving to the clouds Message-ID: rxtx is moving onto a cloud server. You may notice short outages as things move around. So far the following is done. http://rxtx.qbang.org (will redirect rxtx.org there for 2.2) http://bugzilla.qbang.org (bugs) The mail-list is tomorrow night. CVS and FTP will be last. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 8 22:03:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 22:03:26 -0600 (MDT) Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: On Tue, 8 Sep 2009, Nathaniel S. Parsons wrote: > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? Hi Nathaniel, That depends upon what you are running. WinCE is for embedded windows. The Windows source is in src/termios.c (called from src/SerialImp.c). -- Trent Jarvi tjarvi at qbang.org From m.j.tandy at warwick.ac.uk Wed Sep 9 03:27:10 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 10:27:10 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> I had a similar problem a while ago - hardware that would work with Hyperterminal but not with Rxtx. I don't know if this is a bug in RxTx or not - I tried to find where in the RxTx source code those functions are actually implemented - I got as far as the ioctl function in termios.c, where the TIOCMSET case sets the MSR byte in the termios struct, but I can't figure out where that gets written to the dcb struct's fDtrControl dword. It could be a bug, or it could just be me missing something. In any case, at the time I had this problem I wasn't equipped to debug RxTx so instead I created a special cable to satisfy the hardware's flow control while leaving the data connection straight through. Here's how I connected it: At the female end of the cable (i.e. the hardware I was connecting to) I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. I connected the ground and data pins straight through - that is, pin 5 female end to pin 5 male end, pin 2 female end to pin 2 male end, pin 3 female end to pin 3 male end. Anyway, using that cable bypassed the hardware's flow control, and got RxTx working just as well as HyperTerminal - although I slowed down my communication to make sure I didn't encounter a situation where the flow control would have come into effect, as I had bypassed it! Hope that helps. 2009/9/9 Nathaniel S. Parsons : > I added a call to setRTS() but nothing changed in Serial Port Monitor, no > matter what the argument was. Is this a bug, or did I call the wrong > function? > > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? > > -Nate > > On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > wrote: >> >> Thanks for the response. I'll try to get to the electronics store tomorrow >> to get more serial cables, even if it isn't the problem. >> >> I am using a different serial cable than I was in the spring. It's >> actually a Male/Female cable with a female-female adapter since the old >> cables aren't around anymore. The hardware's manual says nothing except to >> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >> should work in RXTX, right? >> >> Anyways, I've also noticed some things that are different between >> HyperTerminal, RXTX, and a separate program I found that communicates with >> the device (but doesn't do what I want, which is why I'm rolling my own >> program) >> >> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >> DTR indicators are green >> Other program - not sure what settings it thinks it's using, but only >> SPM's RTS indicator is green >> RXTX - no matter what flow control I set, only SPM's CTS and DTR >> indicators are on. >> >> From Serial Port Monitor's help files (paraphrased): the indicators >> display the state of the serial control lines >> >> RTS - Request To Send >> CTS - Clear To Send >> DTR - Data Terminal Ready >> >> Could this be related to the problem? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> wrote: >>> >>> OK, so: >>> >>> 1. It worked in spring but has stopped doing so and >>> 2. The data all arrives at once when you start hyperterminal. >>> >>> Is it possible you're using a different serial cable to connect to the >>> device, compared to the one you were using in spring? >>> >>> If so, the issue might be hardware flow control - that is, your device >>> might be buffering data because it can't transmit it until your >>> computer sets 'DTR' or 'RTS' or something like that. >>> >>> One way of bypassing hardware flow control is by using cables which >>> cross over certain wires so that the right signals are always being >>> sent; it's possible your old cable had these connections but your >>> current cable doesn't have them. If you can find the old cable, you >>> could put it back in and see if that fixes things? >>> >>> >>> 2009/9/8 Nathaniel S. Parsons : >>> > (Sorry if this is a double post, but I sent my original message without >>> > subscribing, and since this is an urgent problem, I thought I'd resend >>> > after >>> > subscribing to bypass the moderator limbo zone) >>> > >>> > Hi all, >>> > >>> > I've asked my question on StackOverflow already, so rather than >>> > copy-paste >>> > the question here, I'd like to redirect you there. >>> > >>> > Short version, I am no longer able to receive anything over RS-232 with >>> > RXTX, but other programs work fine. I'm definitely sending things, >>> > because >>> > when I connect with a different program, all the responses to the >>> > commands I >>> > sent via RXTX arrive all at once. >>> > >>> > Everything was fine in the spring, so what could have happened? Windows >>> > update? >>> > >>> > -Nate >>> > >>> > _______________________________________________ >>> > Rxtx mailing list >>> > Rxtx at qbang.org >>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>> > >>> > >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Wed Sep 9 03:54:45 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 12:54:45 +0300 Subject: [Rxtx] Xcode 3.x project available in CVS Message-ID: Hi everyone, I've just committed Apple Xcode 3.x (preferably 3.2) compatible project to CVS. The project can be used to develop and build Mac OS X 10.5+ compatible Universal Binary JNI library and RXTXcomm.jar. It's does not have dependencies to existing Autotools based build scripts - only standard Xcode installation is required. The older Xcode 2.x project is still there, but please note that it's not compatible with newer Xcode versions due to its dependency to deprecated Jam build system. The new project is available in rxtx-devel/MACOSX_IDE/Xcode3 How to get the source code from CVS: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Latest Xcode can be downloaded from Apple: http://developer.apple.com/technology/xcode.html -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 05:07:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 14:07:05 +0300 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: Nathaniel, I agree with Michael that your issue is probably with incorrect hardware flow control (RTS/CTS + possibly DTR/DSR). With RXTX you can do things manually, automatically or by mixing both ways. RXTX is "low-level" enough to let developer make those decisions. Which is proper. Automatic hardware flow-control: If you want to do automatic RTS/CTS flow control in both directions (from and to PC) you must set: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Note that you must combine flow control flags with bitwise OR ( ' | ' ) Manual: If you want to bypass all flow controls signals, or handle them manually you must set: setFlowControlMode( SerialPort.FLOWCONTROL_NONE ); In manual mode, you must manually handle controlling signals from PC and reading flow control signals from by the device: RTS - Request To Send -- setRTS() method can used to set this CTS - Clear To Send -- isCTS() method can be used to read this For example, it is entirely possible to manually implement normal RTS/ CTS flow control with RXTX without relying on low-level automatic implementation. Mixed: You can also configure serial port to handle RTS/CTS automatically in only one direction, then you must set one of: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN ); or setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_OUT ); Then you can either ignore or implement manually the flow control scheme in the other direction. DTR and DSR: These are not officially flow control signals, but might affect external devices (disable, standby etc.). Use and meaning of these depends on the device. DTR - Data Terminal Ready -- setDTR() method DSR - Data Set Ready -- setDSR() method CTS/RTS standards: Please note that there are two standard ways RTS/CTS flow control is done (depends on the device): asymmetric (RS-232) symmetric (RS-232-E / TIA-232-E) For more info see: http://en.wikipedia.org/wiki/RS232#RTS.2FCTS_handshaking Some devices may even use RTS/CTS to some other non-standard purpose. With those devices, enabling automatic RTS/CTS could cause very strange behaviour as they clearly require manual control of CTS/RTS. ---- As far as I know, RXTX properly controls all these signals all the way to actual RS232 pins - unless there is a new platform incompatibility bug that I'm not aware of;) Mostly it's just wrong combination and/or usage of these additional signals that cause problems receiving or sending. And the only solution is to really *know* how your device wants these signals handled - and then code your RXTX application accordingly. Creating non-standard cable is not the right solution in my opinion. Unfortunately some applications (like HyperTerminal for example) might hit more or less accidentally to the right combination of RTS/CTS/DTR/ DSR usage and make RXTX look bad in comparison. While all RXTX does by default is - well - nothing. It gives full control the developer. -- I > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port >> Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I >> found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't >> look wrong >> to me. Am I looking at the right function or is the problem >> somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > > >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store >>> tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since >>> the old >>> cables aren't around anymore. The hardware's manual says nothing >>> except to >>> use a "Straight cable" but I figured that if it worked in >>> HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that >>> communicates with >>> the device (but doesn't do what I want, which is why I'm rolling >>> my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's >>> RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but >>> only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> > >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect >>>> to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your >>>> device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>>> (Sorry if this is a double post, but I sent my original message >>>>> without >>>>> subscribing, and since this is an urgent problem, I thought I'd >>>>> resend >>>>> after >>>>> subscribing to bypass the moderator limbo zone) >>>>> >>>>> Hi all, >>>>> >>>>> I've asked my question on StackOverflow already, so rather than >>>>> copy-paste >>>>> the question here, I'd like to redirect you there. >>>>> >>>>> Short version, I am no longer able to receive anything over >>>>> RS-232 with >>>>> RXTX, but other programs work fine. I'm definitely sending things, >>>>> because >>>>> when I connect with a different program, all the responses to the >>>>> commands I >>>>> sent via RXTX arrive all at once. >>>>> >>>>> Everything was fine in the spring, so what could have happened? >>>>> Windows >>>>> update? >>>>> >>>>> -Nate >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 06:11:11 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 15:11:11 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings Message-ID: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Hi, Summary: Patch includes multiple minor code quality improvements and also fixes one possible null pointer segfault on Mac. After this patch, compilation on Mac OS X is error/warning free even with gcc -Wall setting. I'll submit more code quality patches later that focus more on linux/ win/java. Fixes: Code quality: - First level parentheses around assignment used as while-loop truth value - Some printf formats not a string literals and including no format arguments Invalid null pointer usage: - Mac: IOMasterPort was called with (int)NULL which does not always resolve to segfault safe value. Corrected to use MACH_PORT_NULL instead. Patch: The patch is against CVS head (@2009/09/09). Attached patch file is in 'cvs diff -up' format. I'll commit this patch to the CVS later this week if there are no objections. Feel free to comment. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090909.patch Type: application/octet-stream Size: 1966 bytes Desc: not available URL: From m.j.tandy at warwick.ac.uk Wed Sep 9 06:57:55 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 13:57:55 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> OK, I just ran a test with my copy of RxTx and the following program: import gnu.io.*; public class SerialTest { public static void main(String[] args) { try { CommPortIdentifier portid = CommPortIdentifier.getPortIdentifier("COM9"); SerialPort serialPort = (SerialPort)portid.open("Serial port DTR/RTS test", 1000); serialPort.setSerialPortParams(4800, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.disableReceiveTimeout(); for (int i=0 ; i<60 ; i++) { serialPort.setDTR(true); serialPort.setRTS(true); Thread.sleep(1000); serialPort.setDTR(false); serialPort.setRTS(false); Thread.sleep(1000); } } catch (Exception e) { e.printStackTrace(); System.exit(1); } System.exit(0); } } I'm using a USB-serial converter (Prolific PL-2303) and I used a multimeter to check that my DTR and RTS pins were both toggling, and they were - between +7 and -6.4 volts. In other words, on the computer I'm using at the moment, with the version of RxTx I'm using at the moment, setDTR and setRTS both seem to work fine. I don't know if it's worth it for you to perform the same test. I gather there are several different configurations for hardware flow control, (DTR/DSR handshaking as well as RTS/CTS handshaking, handshaking for half-duplex operation, and similar) so the cable that worked for me might still be worth a try. 2009/9/9 Michael Tandy : > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong >> to me. Am I looking at the right function or is the problem somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since the old >>> cables aren't around anymore. The hardware's manual says nothing except to >>> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that communicates with >>> the device (but doesn't do what I want, which is why I'm rolling my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>> > (Sorry if this is a double post, but I sent my original message without >>>> > subscribing, and since this is an urgent problem, I thought I'd resend >>>> > after >>>> > subscribing to bypass the moderator limbo zone) >>>> > >>>> > Hi all, >>>> > >>>> > I've asked my question on StackOverflow already, so rather than >>>> > copy-paste >>>> > the question here, I'd like to redirect you there. >>>> > >>>> > Short version, I am no longer able to receive anything over RS-232 with >>>> > RXTX, but other programs work fine. I'm definitely sending things, >>>> > because >>>> > when I connect with a different program, all the responses to the >>>> > commands I >>>> > sent via RXTX arrive all at once. >>>> > >>>> > Everything was fine in the spring, so what could have happened? Windows >>>> > update? >>>> > >>>> > -Nate >>>> > >>>> > _______________________________________________ >>>> > Rxtx mailing list >>>> > Rxtx at qbang.org >>>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>>> > >>>> > >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > From david at attglobal.net Wed Sep 9 11:17:27 2009 From: david at attglobal.net (David Schmidt) Date: Wed, 09 Sep 2009 11:17:27 -0400 Subject: [Rxtx] 2.2 Release plans Message-ID: <4AA7C707.5060802@attglobal.net> I'm holding off releasing an update to my project (adtpro.sourceforge.net) to support OSX Snow Leopard because I'd like to ship an "official" build of rxtx 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for toggling a port off). CVS is looking great on OSX - thanks to all who have been hard at work on that. I wish there were just one more update - Pre3? :-) My question... If I wanted to make a release in, say, a week... would it pay to wait for rxtx, or should I plan to build and ship a local build of 2.2 out of CVS myself? - David Schmidt From tjarvi at qbang.org Wed Sep 9 21:14:29 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:14:29 -0600 (MDT) Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: On Wed, 9 Sep 2009, Ilkka Myller wrote: > Hi, > > Summary: > > Patch includes multiple minor code quality improvements and also fixes one > possible null pointer segfault on Mac. > After this patch, compilation on Mac OS X is error/warning free even with gcc > -Wall setting. > I'll submit more code quality patches later that focus more on > linux/win/java. > > Fixes: > > Code quality: > - First level parentheses around assignment used as while-loop truth value > - Some printf formats not a string literals and including no format arguments > > Invalid null pointer usage: > - Mac: IOMasterPort was called with (int)NULL which does not always resolve > to segfault safe value. Corrected to use MACH_PORT_NULL instead. > > Patch: > > The patch is against CVS head (@2009/09/09). > Attached patch file is in 'cvs diff -up' format. > > I'll commit this patch to the CVS later this week if there are no objections. > Feel free to comment. > These ifdefs can go. If you like I can remove them when you are done. #ifdef DEBUG_MW mexErrMsgTxt( msg ); #else They are just printf like debug messages for use in an environment in which I could not get directly to stderr/stdout. I don't think anyone uses them anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Sep 9 21:17:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:17:43 -0600 (MDT) Subject: [Rxtx] 2.2 Release plans In-Reply-To: <4AA7C707.5060802@attglobal.net> References: <4AA7C707.5060802@attglobal.net> Message-ID: On Wed, 9 Sep 2009, David Schmidt wrote: > I'm holding off releasing an update to my project (adtpro.sourceforge.net) to > support OSX Snow Leopard because I'd like to ship an "official" build of rxtx > 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for > toggling a port off). CVS is looking great on OSX - thanks to all who have > been hard at work on that. I wish there were just one more update - Pre3? > :-) > > My question... If I wanted to make a release in, say, a week... would it pay > to wait for rxtx, or should I plan to build and ship a local build of 2.2 out > of CVS myself? > Hi David, I would suggest planning on shipping a local build in a 1 week timeframe. We could put another prerelease up but there are still fixes coming in. -- Trent Jarvi tjarvi at qbang.org From ilkka at myller.com Thu Sep 10 01:07:34 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:07:34 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: <04A41559-598C-4B6E-821A-DA90CB6228E7@myller.com> Patch (im-20090909.patch) has been committed to the CVS. Trent: I'll include DEBUG_MW cleanup to my next patch. > > On Wed, 9 Sep 2009, Ilkka Myller wrote: > >> Hi, >> >> Summary: >> >> Patch includes multiple minor code quality improvements and also >> fixes one possible null pointer segfault on Mac. >> After this patch, compilation on Mac OS X is error/warning free >> even with gcc -Wall setting. >> I'll submit more code quality patches later that focus more on >> linux/win/java. >> >> Fixes: >> >> Code quality: >> - First level parentheses around assignment used as while-loop >> truth value >> - Some printf formats not a string literals and including no format >> arguments >> >> Invalid null pointer usage: >> - Mac: IOMasterPort was called with (int)NULL which does not always >> resolve to segfault safe value. Corrected to use MACH_PORT_NULL >> instead. >> >> Patch: >> >> The patch is against CVS head (@2009/09/09). >> Attached patch file is in 'cvs diff -up' format. >> >> I'll commit this patch to the CVS later this week if there are no >> objections. >> Feel free to comment. >> > > These ifdefs can go. If you like I can remove them when you are done. > > #ifdef DEBUG_MW > mexErrMsgTxt( msg ); > #else > > They are just printf like debug messages for use in an environment > in which I could not get directly to stderr/stdout. I don't think > anyone uses them anymore. > > -- > Trent Jarvi > tjarvi at qbang.org From ilkka at myller.com Thu Sep 10 01:35:13 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:35:13 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= Message-ID: Hi, Summary: Patch fixes compiling on Linux distributions/kernels that dont ship with linux/utsrelease.h header and therefore have no UTS_RELEASE defined. Usually this applies only to newer distributions and/or kernels - for example Ubuntu 9.04. Fixes: The UTS_RELEASE vs uname checking in initialization functions is now done only in debug build and only when UTS_RELEASE is actually defined. Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910.patch Type: application/octet-stream Size: 9542 bytes Desc: not available URL: From ilkka at myller.com Thu Sep 10 08:43:02 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 15:43:02 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= In-Reply-To: References: Message-ID: Patch has been committed to CVS. > Hi, > > Summary: > > Patch fixes compiling on Linux distributions/kernels that dont ship > with linux/utsrelease.h header and therefore have no UTS_RELEASE > defined. > Usually this applies only to newer distributions and/or kernels - > for example Ubuntu 9.04. > > Fixes: > > The UTS_RELEASE vs uname checking in initialization functions is now > done only in debug build and only when UTS_RELEASE is actually > defined. > > Patch: > > The patch is against CVS head (@2009/09/10). > Attached patch file is in 'cvs diff -up' format. > > > Thanks, > > -- > I > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Sep 1 02:38:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 1 Sep 2009 02:38:40 -0600 (MDT) Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks Ilkka The problem should be resolved (confirmed from two locations). I'll be trying to hunt down a Snow Leopard box tomorrow evening as well. On Tue, 1 Sep 2009, Ilkka Myller wrote: > Hi, > > CVS server is reachable, but when trying anonymous login it replies: > > " > Fatal error, aborting. > anonymous: no such system user > " > > It seems that the anonymous cvs account is not yet properly configured on the > new system. > > -- > I > >> On Mon, 31 Aug 2009, Trent Jarvi wrote: >> >> The server has been beemed to another location for those experiencing >> routing problems. >> >> in bash: >> >> export CVSROOT=:pserver:anonymous at qbang.org:2401/var/cvs/cvsroot >> cvs login (no passwd) >> cvs co -r commapi-0-0-1 rxtx-devel >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Tue Sep 1 03:05:59 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 12:05:59 +0300 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks, The new CVS server works well :) I can also confirm that latest CVS version builds properly with unmodified Snow Leopard (Mac OS X 10.6) system: Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 gcc version 4.2.1 (Apple Inc. build 5646) Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) --> Resulting JNI library (Universal Binary): i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = 9d15fc488b301da8bf65b2c9456a7bbb --> Resulting JAR: RXTXComm.jar / 60942 bytes MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 Atleast it builds.. and probably works too. I have not tested that yet. -- I Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > The problem should be resolved (confirmed from two locations). I'll > be trying to hunt down a Snow Leopard box tomorrow evening as well. From jimmy.lee at emotum.com Tue Sep 1 05:07:19 2009 From: jimmy.lee at emotum.com (Jimmy Lee [emotum]) Date: Tue, 1 Sep 2009 21:07:19 +1000 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: <112685a90909010407i6054acb5tc2b12196797bfaf1@mail.gmail.com> Could we access to the binaries? Please :) 2009/9/1 Ilkka Myller > Thanks, > > The new CVS server works well :) > > I can also confirm that latest CVS version builds properly with unmodified > Snow Leopard (Mac OS X 10.6) system: > > Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_I386 i386 > gcc version 4.2.1 (Apple Inc. build 5646) > Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) > > > --> Resulting JNI library (Universal Binary): > > i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes > > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 > librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc > > MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = > 9d15fc488b301da8bf65b2c9456a7bbb > > > --> Resulting JAR: > > RXTXComm.jar / 60942 bytes > > MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 > > > > Atleast it builds.. and probably works too. I have not tested that yet. > > -- > I > > Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > > The problem should be resolved (confirmed from two locations). I'll be >> trying to hunt down a Snow Leopard box tomorrow evening as well. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Tue Sep 1 06:21:28 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Tue, 1 Sep 2009 08:21:28 -0400 (EDT) Subject: [Rxtx] Snow Leopard binaries Message-ID: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> +1 for binaries - pretty please with sugar on top... -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com From fredm at alum.mit.edu Tue Sep 1 06:24:17 2009 From: fredm at alum.mit.edu (Fred G. Martin) Date: Tue, 1 Sep 2009 08:24:17 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> Message-ID: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> You can find one here: http://iharder.sourceforge.net/current/java/ Also, you need to add yourself (any rxtx user) to the uucp group. Niutils don't exist, but dscl is a replacement. There is info for using it here: http://aplawrence.com/MacOSX/directory_services.html Fred On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Tue Sep 1 07:03:37 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Tue, 1 Sep 2009 18:33:37 +0530 Subject: [Rxtx] Help for RXTX on mac Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time I am able to read the device but on second time, it hangs on COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then it was showing the PortInUseException, I replaced the RXTX library to 2.2Pre1 so it is showing this problem. Is this is a problem with RXTX on Mac? Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: From ilkka at myller.com Tue Sep 1 07:57:06 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 16:57:06 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:02:31 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:02:31 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:43:49 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:43:49 +0300 Subject: [Rxtx] Help for RXTX on mac In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE@myller.com> Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Arseneau at Sun.COM Tue Sep 1 08:51:32 2009 From: Eric.Arseneau at Sun.COM (Eric Arseneau) Date: Tue, 01 Sep 2009 07:51:32 -0700 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24@sun.com> Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 09:24:30 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 18:24:30 +0300 Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D@myller.com> Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Thu Sep 3 02:50:16 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Thu, 3 Sep 2009 10:50:16 +0200 Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s From Kapil_Gupta at hcl.in Thu Sep 3 06:52:21 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:22:21 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From Kapil_Gupta at hcl.in Thu Sep 3 07:15:19 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:45:19 +0530 Subject: [Rxtx] Rxtx Digest, Vol 25, Issue 3 In-Reply-To: References: Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C50BB@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi myller, I have attached the code with the mail. Please help me if I am doing something wrong in it. Thanks & Regards, Kapil Gupta -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of rxtx-request at qbang.org Sent: Thursday, September 03, 2009 4:15 PM To: rxtx at qbang.org Subject: Rxtx Digest, Vol 25, Issue 3 Send Rxtx mailing list submissions to rxtx at qbang.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qbang.org/mailman/listinfo/rxtx or, via email, send a message with subject or body 'help' to rxtx-request at qbang.org You can reach the person managing the list at rxtx-owner at qbang.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Rxtx digest..." Today's Topics: 1. Re: Snow Leopard binaries (Ilkka Myller) 2. Re: Snow Leopard binaries (Ilkka Myller) 3. Re: Help for RXTX on mac (Ilkka Myller) 4. Re: Snow Leopard binaries (Eric Arseneau) 5. Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters (Ilkka Myller) 6. RXTX multiple crashes (Kjetil ?ster?s) 7. RXTX 2.2Pre + MacMini+ Deadlock while second time port open (Kapil Gupta) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Sep 2009 16:57:06 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 1 Sep 2009 17:02:31 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <55EC133D-DC83-45A3-849C-02714904D580 at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 1 Sep 2009 17:43:49 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Help for RXTX on mac Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Tue, 01 Sep 2009 07:51:32 -0700 From: Eric Arseneau Cc: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24 at sun.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 1 Sep 2009 18:24:30 +0300 From: Ilkka Myller To: rxtx Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Thu, 3 Sep 2009 10:50:16 +0200 From: Kjetil ?ster?s To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s ------------------------------ Message: 7 Date: Thu, 3 Sep 2009 18:22:21 +0530 From: Kapil Gupta To: "rxtx at qbang.org" Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059 at NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset="us-ascii" Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: ------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx End of Rxtx Digest, Vol 25, Issue 3 *********************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From ilkka at myller.com Thu Sep 3 11:17:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 3 Sep 2009 20:17:27 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <4520677F-E8F0-46F5-B4AD-3AD3A7C2AED3@myller.com> Hi Kapil, The code is incomplete and I did not find anything I could to test/ debug with this. I also tried to find the actual serial port opening, but found only a call to missing method which creates the SerialPort object (?): serialPort = getSerialPortConnection( COMPort, this.readEvent.getDeviceName(), SerialCommConfig.DEVICE1[SerialCommConfig.TIMEOUT], SerialCommConfig.DEVICE1[SerialCommConfig.BAUDRATE], SerialCommConfig.DEVICE1[SerialCommConfig.DATABITS], SerialCommConfig.DEVICE1[SerialCommConfig.STOPBITS], SerialCommConfig.DEVICE1[SerialCommConfig.PARITY] ); The class SerialCommConfig is missing too. If this is a part of the actual code you are using, please note that you are not actually closing the serial port. The call to close() method is commented out: try { // serialPort.close(); } catch (Exception ex) { ex.printStackTrace(); } Re-opening of the serial port wont work if you haven't properly closed it first. -- I > > I am using RXTX on Macintosh to communicate to my device. First time > the device responds well but on second time, it hangs on > COMPort.open (name, timeout). > > I have attached the source code in a file. Please help me. > > Thanks & Best Regards, > Kapil -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorton at intellimec.com Thu Sep 3 11:37:55 2009 From: dmorton at intellimec.com (Daniel Morton) Date: Thu, 3 Sep 2009 13:37:55 -0400 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. (I haven't tried previous version though). Daniel Morton Java/J2EE Developer Tel +1 519.745.8887 x4331 Email dmorton at intellimec.com www.intellimec.com | www.iLane.com | www.drivesync.com Intelligent Mechatronic Systems Inc. 435 King Street North Waterloo, ON N2J 2Z5 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s Sent: Thursday, September 03, 2009 4:50 AM To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. From alexanderkiel at gmx.net Fri Sep 4 02:29:15 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 10:29:15 +0200 Subject: [Rxtx] Official Javadoc Location Message-ID: <1252052955.4025.80.camel@T61-KIEL> Hi List, I wasn't able to find an official location of RXTX Javadoc accessible over HTTP. Maybe someone can link me to it. If there is no such location, I would like to see one. I like to link from my own Javadoc to such a location. Thanks Alexander - e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:19:25 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:19:25 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> Message-ID: <1252055965.4025.84.camel@T61-KIEL> Hi Michael, thanks for the pointer. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 09:48 +0100, Michael Tandy wrote: > RxTx javadoc: http://users.frii.com/jarvi/rxtx/doc/index.html > Javax interface RxTx duplicates javadoc: > http://java.sun.com/products/javacomm/reference/api/index.html > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:22:14 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:22:14 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> Message-ID: <1252056134.4025.87.camel@T61-KIEL> Hi Eike, thanks, but I need a direct package pointer so that Javadoc will link the gnu.io packages automatically to the right location. Michael has pointed me to http://users.frii.com/jarvi/rxtx/doc/index.html which has the gnu.io packages. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 11:04 +0200, Eike Hinderk J?rrens wrote: > Hi Alexander, > it seems to me that RXTX is implementing this API: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Kind regards, > Eike > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kjetilos at gmail.com Fri Sep 4 03:43:41 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 11:43:41 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> Message-ID: <7a803d460909040243ke4449ecucbe2cd8b15761746@mail.gmail.com> Hi Daniel, This is interesting, what type of application are you making? Is there a lot of signaling on different COM ports at the same time in your application? In our application we have 11 devices connected to different COM ports, 9 of these are in active use when the application is running. I'm wondering how to use the RXTX library version 2.1.7 in this scenario without causing it to crash. After adding more signaling on the COM ports in our application we have now experienced other crashes and it is natural to think that it has something to do with our way of using RXTX from several threads at the same time. So my question is are there any methods like read/write/flush/close that are not thread safe and should be handled with care? And similarly is the RXTXPort.SerialInputStream and RXTXPort.SerialOutputStream thread safe? 2009/9/3 Daniel Morton : > I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. ?(I haven't tried previous version though). > > Daniel Morton > Java/J2EE Developer > > Tel ? ?+1 519.745.8887 x4331 > Email ? ?dmorton at intellimec.com > > > www.intellimec.com ?| ?www.iLane.com ?| ?www.drivesync.com > > > > Intelligent Mechatronic Systems Inc. > 435 King Street North Waterloo, ON N2J 2Z5 > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s > Sent: Thursday, September 03, 2009 4:50 AM > To: rxtx at qbang.org > Subject: [Rxtx] RXTX multiple crashes > > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x7d0d] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0ce75800): ?JavaThread "Y Worker" daemon > [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 > > Registers: > EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 > ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 > EIP=0x10007d0d, EFLAGS=0x00010202 > > Top of Stack: (sp=0x0d7ff6d8) > 0x0d7ff6d8: ? 0d7ff700 00000000 00000000 00000000 > 0x0d7ff6e8: ? 02a2eae8 00000123 00002958 0d7ff718 > 0x0d7ff6f8: ? 7c830887 7c90d28a 7c8664b5 00000e2c > 0x0d7ff708: ? 00002958 00000000 00000000 7c90cffa > 0x0d7ff718: ? 7c809bdb 00002958 0d7ff758 00000e40 > 0x0d7ff728: ? 00002958 02bd0468 0ce75800 080e4ee0 > 0x0d7ff738: ? 00000000 00000000 00000000 00000000 > 0x0d7ff748: ? 00000000 00000000 00000014 7c90d09a > > Instructions: (pc=0x10007d0d) > 0x10007cfd: ? 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 > 0x10007d0d: ? 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 > > > Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x7d0d] > J ?gnu.io.RXTXPort.nativeDrain(Z)Z > J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > ... > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x9c55] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0cddf400): ?JavaThread "XXX Worker" daemon > [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 > > Registers: > EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 > ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 > EIP=0x10009c55, EFLAGS=0x00010206 > > Top of Stack: (sp=0x0bb8f830) > 0x0bb8f830: ? 00000000 00000000 c0000005 00000000 > 0x0bb8f840: ? 00000000 00f1f0a5 00000002 00000000 > 0x0bb8f850: ? 003a0100 0001003f 0bb8fb20 0b9ff918 > 0x0bb8f860: ? 00000000 00000000 0bb8fb68 0bb8fb20 > 0x0bb8f870: ? 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 > 0x0bb8f880: ? 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 > 0x0bb8f890: ? 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 > 0x0bb8f8a0: ? 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 > > Instructions: (pc=0x10009c55) > 0x10009c45: ? 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff > 0x10009c55: ? 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 > > > Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x9c55] > C ?[rxtxSerial.dll+0xa05e] > J ?gnu.io.RXTXPort.readByte()I > J ?gnu.io.RXTXPort$SerialInputStream.read()I > J ?java.io.FilterInputStream.read()I > ... > > -- > Kjetil ?ster?s > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kjetil ?ster?s From tjarvi at qbang.org Fri Sep 4 06:00:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Sep 2009 06:00:40 -0600 (MDT) Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x7d0d] > J gnu.io.RXTXPort.nativeDrain(Z)Z > J gnu.io.RXTXPort$SerialOutputStream.flush()V > Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x9c55] > C [rxtxSerial.dll+0xa05e] > J gnu.io.RXTXPort.readByte()I > J gnu.io.RXTXPort$SerialInputStream.read()I RXTX 2.1-7 has concurrency issues that will show upon multicore systems. These should be resolved in the 2.2 pre release. A user application could synchronize the read/write/open/close calls while using 2.1 to avoid the concurrency issue. The flush is probably following a write while the readByte is coming from read(byte b). The bugs existed in rxtx for a long time. I assume changes in the JVM and the presence of multicore systems exposed the issues. -- Trent Jarvi tjarvi at qbang.org From kjetilos at gmail.com Fri Sep 4 06:33:33 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 14:33:33 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <7a803d460909040533n1caf240y8168477a578bc45c@mail.gmail.com> Den 4. september 2009 14.00 skrev Trent Jarvi f?lgende: > > > On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > >> Hi >> >> We are using RXTX version 2.1.7 actively and lately we are having some >> issues with the RXTX library crashing. We are running a windows xp >> system with multiple COM ports where each COM port have a serial >> device connected. Lately we have increased the amount of signaling >> done over the COM ports and we are experiencing several odd crashes. I >> tried to search the mailinglist for something similar but was unable >> to find anything. At one time the RXTX crashed in the >> gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the >> gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack >> traces if someone is interested in having a look. Has anyone seen the >> same crashes? and does anyone know what can cause such crash? >> >> >> Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x7d0d] >> J ?gnu.io.RXTXPort.nativeDrain(Z)Z >> J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > >> Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x9c55] >> C ?[rxtxSerial.dll+0xa05e] >> J ?gnu.io.RXTXPort.readByte()I >> J ?gnu.io.RXTXPort$SerialInputStream.read()I > > > RXTX 2.1-7 has concurrency issues that will show upon multicore systems. > These should be resolved in the 2.2 pre release. ?A user application could > synchronize the read/write/open/close calls while using 2.1 to avoid the > concurrency issue. > > The flush is probably following a write while the readByte is coming from > read(byte b). > > The bugs existed in rxtx for a long time. ?I assume changes in the JVM and > the presence of multicore systems exposed the issues. > Ok, so we should look more into using a newer version of RXTX. The current version from the webpage is 2.2pre2, what is the stability status of this version. Is it good enough for use in a production environment? -- Kjetil ?ster?s From martinezrodolfo at gmail.com Fri Sep 4 13:39:57 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Fri, 4 Sep 2009 15:09:57 -0430 Subject: [Rxtx] Problem with data available event Message-ID: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Hello list members. I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a serial port USB adapter to communicate with an electronical inmunoassay analyzer. The program works porperly with one model of the analyzer series. It defines a protocol which every message sent should be replied with an ACK in order to continue with the communication. Now we are trying to communicate with another model of the same brand and series wich in theory should be much of the same of what was previously done. Unfortunately, that is not the case. The problem with this connection is that it never fires the Data Available serial port event. Is like if nothing was being received in the input stream. The following code always prints zero when the equipment should be transmitting. ----------------------- beginning of sample code ---------------------------------- SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", 10000); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); int len = 0; byte[] readBuffer = new byte[8]; while (true) { len = in.read(readBuffer); System.out.println(len); writer.writeACK(); // writing ACK to analyzer } ----------------------- end of sample code ------------------------------------------ We know that the analyzer is transmitting because HyperTerminal does shows the proper output. In fact, after running the above code and connecting via Hyperterminal all data is received in one block. Is like the data sent from the analyzer is being held somewhere in the way. Sniffing at the serial port, noticed that IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this helps to find what might be wrong or not, but here they are: On Hyperterminal: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 XonLimit:80 XoffLimit:200 On Java: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 XonLimit:0 XoffLimit:0 Thanks in advance for your help. Rodolfo M From ilkka at myller.com Sat Sep 5 04:36:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 5 Sep 2009 13:36:27 +0300 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <121198EE-65A4-463B-ACC7-29FFB9855B2C@myller.com> Hi Rodolfo, By default RXTX does not enable any flow control for the serial port. Please check what flow control you have active in HyperTerminal when you are able to receive data and then use the same flow control with RXTX serial port: serialPort.setFlowControlMode(int flowcontrol); Possible flowcontrol flags are (from SerialPort class) FLOWCONTROL_NONE FLOWCONTROL_RTSCTS_IN FLOWCONTROL_RTSCTS_OUT FLOWCONTROL_XONXOFF_IN FLOWCONTROL_XONXOFF_OUT For example, you can try enabling RTS/CTS hardware flow control. Note the bitwise OR operator ' | ': serialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Also if your device requires RTS/CTS flow control make sure you have fully connected serial cable (not just RX, TX, GND for example, but also RTS, CTS, DTR). One thing you might want to check is the state of DTR (Data Terminal Ready). Some devices wait for the DTR signal before they send any data. You can enable or disable DTR signal (high/low) with: serialPort.setDTR( boolean state ); -- I > Hello list members. > > I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a > serial port USB adapter to communicate with an electronical > inmunoassay analyzer. The program works porperly with one model of the > analyzer series. It defines a protocol which every message sent should > be replied with an ACK in order to continue with the communication. > Now we are trying to communicate with another model of the same brand > and series wich in theory should be much of the same of what was > previously done. Unfortunately, that is not the case. The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. > > ----------------------- beginning of sample code > ---------------------------------- > SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", > 10000); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > InputStream in = serialPort.getInputStream(); > OutputStream out = serialPort.getOutputStream(); > > int len = 0; > byte[] readBuffer = new byte[8]; > while (true) { > len = in.read(readBuffer); > System.out.println(len); > > writer.writeACK(); // writing ACK to analyzer > } > ----------------------- end of sample code > ------------------------------------------ > > We know that the analyzer is transmitting because HyperTerminal does > shows the proper output. In fact, after running the above code and > connecting via Hyperterminal all data is received in one block. Is > like the data sent from the analyzer is being held somewhere in the > way. Sniffing at the serial port, noticed that > IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this > helps to find what might be wrong or not, but here they are: > > On Hyperterminal: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 > XonLimit:80 XoffLimit:200 > > On Java: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 > XonLimit:0 XoffLimit:0 > > > Thanks in advance for your help. > Rodolfo M > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.weber99 at gmx.net Sun Sep 6 13:51:12 2009 From: karl.weber99 at gmx.net (Karl Weber) Date: Sun, 6 Sep 2009 21:51:12 +0200 Subject: [Rxtx] Cannot create lock file Message-ID: <200909062151.12228.karl.weber99@gmx.net> Hi, I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an opensuse repository as well as from the homepage of the rxtx project. I have already added the user to the group uucp, however, it does not have any effect. What else do I have to do to make it work? (It does work with user root, though.) The error message is: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL Thanks in advance, Karl From tjarvi at qbang.org Sun Sep 6 13:51:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 6 Sep 2009 13:51:42 -0600 (MDT) Subject: [Rxtx] Cannot create lock file In-Reply-To: <200909062151.12228.karl.weber99@gmx.net> References: <200909062151.12228.karl.weber99@gmx.net> Message-ID: On Sun, 6 Sep 2009, Karl Weber wrote: > Hi, > > I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an > opensuse repository as well as from the homepage of the rxtx project. > > I have already added the user to the group uucp, however, it does not have > any effect. What else do I have to do to make it work? (It does work with > user root, though.) > > The error message is: > > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to > create lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > > Thanks in advance, Karl Look at the group that owns /var/lock with ls -ld /var/lock The following should work as a user when they are in the correct group: touch /var/lock/test && rm -f /var/lock/test -- Trent Jarvi tjarvi at qbang.org From Luca.Catoni at sysdat.it Mon Sep 7 06:32:42 2009 From: Luca.Catoni at sysdat.it (Luca Catoni) Date: Mon, 7 Sep 2009 14:32:42 +0200 Subject: [Rxtx] time-out implementation Message-ID: I need to implement a simple timer class to manage time-out in my RS-232 serial communication with a remote device using the rxtx library. The functions that the timer should have are start(), and reset() and start() method must throw an exception (TimeoutException) when it expires. I am not an expert in concurrent programming and I do not have much knowledge on threads. myTimer.setExpirationTime(myvalue); ? public void serialEvent(SerialPortEvent event) { if (event.getEventType() == SerialPortEvent.OUTPUT_BUFFER_EMPTY) { // transmission ? out.write(?); try{ myTimer.start(); }catch(TimeoutException te){ myTimer.reset(); ? } ? if (event.getEventType() == SerialPortEvent.DATA_AVAILABLE) { // receiving in.read(?); if (mycondition){ myTimer.stop();//ok, timer NOT expired myTimer.reset();//now I can call start() method again in //transmission to restart my timer when I //have to transmit next data } Can anyone help me to implement the class MyTimer? thanks in advance. -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Mon Sep 7 06:49:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Mon, 7 Sep 2009 18:19:24 +0530 Subject: [Rxtx] 2.2Pre + MacMini+ Deadlock while second time port Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E22FB6F@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, Please find the updated code (close call was commented by mistake). This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From michael.erskine at ketech.com Mon Sep 7 09:13:03 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 7 Sep 2009 16:13:03 +0100 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Rodolfo Mart?nez > Subject: [Rxtx] Problem with data available event > The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. Hi Rodolfo, The sample code you provided doesn't implement or register any event listeners. Regards, Michael Erskine. From martinezrodolfo at gmail.com Mon Sep 7 10:21:22 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Mon, 7 Sep 2009 11:51:22 -0430 Subject: [Rxtx] Problem with data available event In-Reply-To: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> Message-ID: <30eacee0909070921l7f285765ue2c661963183fd2b@mail.gmail.com> On Mon, Sep 7, 2009 at 10:43 AM, Michael Erskine wrote: > Hi Rodolfo, > The sample code you provided doesn't implement or register any event listeners. > > Regards, > Michael Erskine. Hi Michael, I didn't write the event listeners declaration on the sample code for simplicity, but I do implement them on my real code. I should have mentioned it on the sample code anyway... my bad. I haven't had access to the device I'm trying to connect, but tomorrow will. And hope that with the explanation of Ilkka Myller will succeed this time. Thanks for your attention. Rodolfo M From ajmas at sympatico.ca Mon Sep 7 16:58:13 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 7 Sep 2009 18:58:13 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" I noticed in the page you posted posted you indicated that you patched two files. Did you submit the changes to Jarvi, so they could be included in the main code branch? Andr? From tjarvi at qbang.org Mon Sep 7 16:57:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Sep 2009 16:57:53 -0600 (MDT) Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On Mon, 7 Sep 2009, Andre-John Mas wrote: > > On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > >> Sorry, my rudeness was not intentional (a typo). >> Lets try again.. ;) >> >> "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > I noticed in the page you posted posted you indicated that you patched two > files. Did you submit the changes to Jarvi, so they could be included in the > main code branch? > Hi Andr? Ilkka is working with us to get changes in. I'm not sure about those two patches which may already be in CVS. I'll let him answer that. I've given him write access to CVS and asked him to cc the list non whitespace changes when they are ready. Right now he is asking questions off the list regarding cleaning up the Mac and w32 build files. -- Trent Jarvi tjarvi at qbang.org From nsp25 at cornell.edu Mon Sep 7 21:17:45 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Mon, 7 Sep 2009 23:17:45 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: (Sorry if this is a double post, but I sent my original message without subscribing, and since this is an urgent problem, I thought I'd resend after subscribing to bypass the moderator limbo zone) Hi all, I've asked my question on StackOverflow already, so rather than copy-paste the question here, I'd like to redirect you there . Short version, I am no longer able to receive anything over RS-232 with RXTX, but other programs work fine. I'm definitely sending things, because when I connect with a different program, all the responses to the commands I sent via RXTX arrive all at once. Everything was fine in the spring, so what could have happened? Windows update? -Nate -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.j.tandy at warwick.ac.uk Tue Sep 8 01:30:48 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Tue, 8 Sep 2009 08:30:48 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> OK, so: 1. It worked in spring but has stopped doing so and 2. The data all arrives at once when you start hyperterminal. Is it possible you're using a different serial cable to connect to the device, compared to the one you were using in spring? If so, the issue might be hardware flow control - that is, your device might be buffering data because it can't transmit it until your computer sets 'DTR' or 'RTS' or something like that. One way of bypassing hardware flow control is by using cables which cross over certain wires so that the right signals are always being sent; it's possible your old cable had these connections but your current cable doesn't have them. If you can find the old cable, you could put it back in and see if that fixes things? 2009/9/8 Nathaniel S. Parsons : > (Sorry if this is a double post, but I sent my original message without > subscribing, and since this is an urgent problem, I thought I'd resend after > subscribing to bypass the moderator limbo zone) > > Hi all, > > I've asked my question on StackOverflow already, so rather than copy-paste > the question here, I'd like to redirect you there. > > Short version, I am no longer able to receive anything over RS-232 with > RXTX, but other programs work fine. I'm definitely sending things, because > when I connect with a different program, all the responses to the commands I > sent via RXTX arrive all at once. > > Everything was fine in the spring, so what could have happened? Windows > update? > > -Nate > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Tue Sep 8 01:50:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 8 Sep 2009 10:50:33 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <111FEC9A-26BA-435C-BABC-314C7E4F23E5@myller.com> Hi all, Patches applied to the 2.1.7 binaries distributed by Robert Harder (http://iharder.sourceforge.net/current/java/ ) are already in the 2.2. Actually in 2.2 the issue with integer types handling seems to be fixed even more extensively than that single patch to 2.1.7 originally did. And yes, Trent has granted me CVS commit access. Thank you. First thing I'm going to focus on is the code quality and clean up: unused variables, invalid pointer usage etc.. Most of this just causing compile warnings - some harmless and some have potential for causing runtime problems. Instead of just blindly committing new changes to CVS, I've been discussing with Trent about the way things have been done in the RXTX CVS before. (how to handle white space patches, what needs to be discussed with the list first, proper locations for new files/ directories/subprojects, "the way things are done in RXTX"). But patches are coming and bugs will be fixed. I hope everyone will continue to submit the bugs they discover to this mailing list. Most important thing is to provide enough info (code;) so that the issue can be duplicated and eventually fixed. -- I > > > On Mon, 7 Sep 2009, Andre-John Mas wrote: >> >> I noticed in the page you posted posted you indicated that you >> patched two files. Did you submit the changes to Jarvi, so they >> could be included in the main code branch? >> > > Ilkka is working with us to get changes in. I'm not sure about > those two patches which may already be in CVS. I'll let him answer > that. > > I've given him write access to CVS and asked him to cc the list non > whitespace changes when they are ready. Right now he is asking > questions off the list regarding cleaning up the Mac and w32 build > files. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 15:35:19 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 17:35:19 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: Thanks for the response. I'll try to get to the electronics store tomorrow to get more serial cables, even if it isn't the problem. I am using a different serial cable than I was in the spring. It's actually a Male/Female cable with a female-female adapter since the old cables aren't around anymore. The hardware's manual says nothing except to use a "Straight cable" but I figured that if it worked in HyperTerminal, it should work in RXTX, right? Anyways, I've also noticed some things that are different between HyperTerminal, RXTX, and a separate program I found that communicates with the device (but doesn't do what I want, which is why I'm rolling my own program) HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and DTR indicators are green Other program - not sure what settings it thinks it's using, but only SPM's RTS indicator is green RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators are on. >From Serial Port Monitor's help files (paraphrased): the indicators display the state of the serial control lines RTS - Request To Send CTS - Clear To Send DTR - Data Terminal Ready Could this be related to the problem? -Nate On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > OK, so: > > 1. It worked in spring but has stopped doing so and > 2. The data all arrives at once when you start hyperterminal. > > Is it possible you're using a different serial cable to connect to the > device, compared to the one you were using in spring? > > If so, the issue might be hardware flow control - that is, your device > might be buffering data because it can't transmit it until your > computer sets 'DTR' or 'RTS' or something like that. > > One way of bypassing hardware flow control is by using cables which > cross over certain wires so that the right signals are always being > sent; it's possible your old cable had these connections but your > current cable doesn't have them. If you can find the old cable, you > could put it back in and see if that fixes things? > > > 2009/9/8 Nathaniel S. Parsons : > > (Sorry if this is a double post, but I sent my original message without > > subscribing, and since this is an urgent problem, I thought I'd resend > after > > subscribing to bypass the moderator limbo zone) > > > > Hi all, > > > > I've asked my question on StackOverflow already, so rather than > copy-paste > > the question here, I'd like to redirect you there. > > > > Short version, I am no longer able to receive anything over RS-232 with > > RXTX, but other programs work fine. I'm definitely sending things, > because > > when I connect with a different program, all the responses to the > commands I > > sent via RXTX arrive all at once. > > > > Everything was fine in the spring, so what could have happened? Windows > > update? > > > > -Nate > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 18:57:58 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 20:57:58 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: I added a call to setRTS() but nothing changed in Serial Port Monitor, no matter what the argument was. Is this a bug, or did I call the wrong function? I tried to find the c code behind this function, and I think I found it in rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong to me. Am I looking at the right function or is the problem somewhere else? -Nate On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons wrote: > Thanks for the response. I'll try to get to the electronics store tomorrow > to get more serial cables, even if it isn't the problem. > > I am using a different serial cable than I was in the spring. It's actually > a Male/Female cable with a female-female adapter since the old cables aren't > around anymore. The hardware's manual says nothing except to use a "Straight > cable" but I figured that if it worked in HyperTerminal, it should work in > RXTX, right? > > Anyways, I've also noticed some things that are different between > HyperTerminal, RXTX, and a separate program I found that communicates with > the device (but doesn't do what I want, which is why I'm rolling my own > program) > > HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and > DTR indicators are green > Other program - not sure what settings it thinks it's using, but only SPM's > RTS indicator is green > RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators > are on. > > From Serial Port Monitor's help files (paraphrased): the indicators display > the state of the serial control lines > > RTS - Request To Send > CTS - Clear To Send > DTR - Data Terminal Ready > > Could this be related to the problem? > > -Nate > > > On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > >> OK, so: >> >> 1. It worked in spring but has stopped doing so and >> 2. The data all arrives at once when you start hyperterminal. >> >> Is it possible you're using a different serial cable to connect to the >> device, compared to the one you were using in spring? >> >> If so, the issue might be hardware flow control - that is, your device >> might be buffering data because it can't transmit it until your >> computer sets 'DTR' or 'RTS' or something like that. >> >> One way of bypassing hardware flow control is by using cables which >> cross over certain wires so that the right signals are always being >> sent; it's possible your old cable had these connections but your >> current cable doesn't have them. If you can find the old cable, you >> could put it back in and see if that fixes things? >> >> >> 2009/9/8 Nathaniel S. Parsons : >> > (Sorry if this is a double post, but I sent my original message without >> > subscribing, and since this is an urgent problem, I thought I'd resend >> after >> > subscribing to bypass the moderator limbo zone) >> > >> > Hi all, >> > >> > I've asked my question on StackOverflow already, so rather than >> copy-paste >> > the question here, I'd like to redirect you there. >> > >> > Short version, I am no longer able to receive anything over RS-232 with >> > RXTX, but other programs work fine. I'm definitely sending things, >> because >> > when I connect with a different program, all the responses to the >> commands I >> > sent via RXTX arrive all at once. >> > >> > Everything was fine in the spring, so what could have happened? Windows >> > update? >> > >> > -Nate >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Tue Sep 8 21:54:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 21:54:26 -0600 (MDT) Subject: [Rxtx] rxtx is moving to the clouds Message-ID: rxtx is moving onto a cloud server. You may notice short outages as things move around. So far the following is done. http://rxtx.qbang.org (will redirect rxtx.org there for 2.2) http://bugzilla.qbang.org (bugs) The mail-list is tomorrow night. CVS and FTP will be last. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 8 22:03:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 22:03:26 -0600 (MDT) Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: On Tue, 8 Sep 2009, Nathaniel S. Parsons wrote: > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? Hi Nathaniel, That depends upon what you are running. WinCE is for embedded windows. The Windows source is in src/termios.c (called from src/SerialImp.c). -- Trent Jarvi tjarvi at qbang.org From m.j.tandy at warwick.ac.uk Wed Sep 9 03:27:10 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 10:27:10 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> I had a similar problem a while ago - hardware that would work with Hyperterminal but not with Rxtx. I don't know if this is a bug in RxTx or not - I tried to find where in the RxTx source code those functions are actually implemented - I got as far as the ioctl function in termios.c, where the TIOCMSET case sets the MSR byte in the termios struct, but I can't figure out where that gets written to the dcb struct's fDtrControl dword. It could be a bug, or it could just be me missing something. In any case, at the time I had this problem I wasn't equipped to debug RxTx so instead I created a special cable to satisfy the hardware's flow control while leaving the data connection straight through. Here's how I connected it: At the female end of the cable (i.e. the hardware I was connecting to) I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. I connected the ground and data pins straight through - that is, pin 5 female end to pin 5 male end, pin 2 female end to pin 2 male end, pin 3 female end to pin 3 male end. Anyway, using that cable bypassed the hardware's flow control, and got RxTx working just as well as HyperTerminal - although I slowed down my communication to make sure I didn't encounter a situation where the flow control would have come into effect, as I had bypassed it! Hope that helps. 2009/9/9 Nathaniel S. Parsons : > I added a call to setRTS() but nothing changed in Serial Port Monitor, no > matter what the argument was. Is this a bug, or did I call the wrong > function? > > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? > > -Nate > > On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > wrote: >> >> Thanks for the response. I'll try to get to the electronics store tomorrow >> to get more serial cables, even if it isn't the problem. >> >> I am using a different serial cable than I was in the spring. It's >> actually a Male/Female cable with a female-female adapter since the old >> cables aren't around anymore. The hardware's manual says nothing except to >> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >> should work in RXTX, right? >> >> Anyways, I've also noticed some things that are different between >> HyperTerminal, RXTX, and a separate program I found that communicates with >> the device (but doesn't do what I want, which is why I'm rolling my own >> program) >> >> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >> DTR indicators are green >> Other program - not sure what settings it thinks it's using, but only >> SPM's RTS indicator is green >> RXTX - no matter what flow control I set, only SPM's CTS and DTR >> indicators are on. >> >> From Serial Port Monitor's help files (paraphrased): the indicators >> display the state of the serial control lines >> >> RTS - Request To Send >> CTS - Clear To Send >> DTR - Data Terminal Ready >> >> Could this be related to the problem? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> wrote: >>> >>> OK, so: >>> >>> 1. It worked in spring but has stopped doing so and >>> 2. The data all arrives at once when you start hyperterminal. >>> >>> Is it possible you're using a different serial cable to connect to the >>> device, compared to the one you were using in spring? >>> >>> If so, the issue might be hardware flow control - that is, your device >>> might be buffering data because it can't transmit it until your >>> computer sets 'DTR' or 'RTS' or something like that. >>> >>> One way of bypassing hardware flow control is by using cables which >>> cross over certain wires so that the right signals are always being >>> sent; it's possible your old cable had these connections but your >>> current cable doesn't have them. If you can find the old cable, you >>> could put it back in and see if that fixes things? >>> >>> >>> 2009/9/8 Nathaniel S. Parsons : >>> > (Sorry if this is a double post, but I sent my original message without >>> > subscribing, and since this is an urgent problem, I thought I'd resend >>> > after >>> > subscribing to bypass the moderator limbo zone) >>> > >>> > Hi all, >>> > >>> > I've asked my question on StackOverflow already, so rather than >>> > copy-paste >>> > the question here, I'd like to redirect you there. >>> > >>> > Short version, I am no longer able to receive anything over RS-232 with >>> > RXTX, but other programs work fine. I'm definitely sending things, >>> > because >>> > when I connect with a different program, all the responses to the >>> > commands I >>> > sent via RXTX arrive all at once. >>> > >>> > Everything was fine in the spring, so what could have happened? Windows >>> > update? >>> > >>> > -Nate >>> > >>> > _______________________________________________ >>> > Rxtx mailing list >>> > Rxtx at qbang.org >>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>> > >>> > >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Wed Sep 9 03:54:45 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 12:54:45 +0300 Subject: [Rxtx] Xcode 3.x project available in CVS Message-ID: Hi everyone, I've just committed Apple Xcode 3.x (preferably 3.2) compatible project to CVS. The project can be used to develop and build Mac OS X 10.5+ compatible Universal Binary JNI library and RXTXcomm.jar. It's does not have dependencies to existing Autotools based build scripts - only standard Xcode installation is required. The older Xcode 2.x project is still there, but please note that it's not compatible with newer Xcode versions due to its dependency to deprecated Jam build system. The new project is available in rxtx-devel/MACOSX_IDE/Xcode3 How to get the source code from CVS: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Latest Xcode can be downloaded from Apple: http://developer.apple.com/technology/xcode.html -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 05:07:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 14:07:05 +0300 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: Nathaniel, I agree with Michael that your issue is probably with incorrect hardware flow control (RTS/CTS + possibly DTR/DSR). With RXTX you can do things manually, automatically or by mixing both ways. RXTX is "low-level" enough to let developer make those decisions. Which is proper. Automatic hardware flow-control: If you want to do automatic RTS/CTS flow control in both directions (from and to PC) you must set: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Note that you must combine flow control flags with bitwise OR ( ' | ' ) Manual: If you want to bypass all flow controls signals, or handle them manually you must set: setFlowControlMode( SerialPort.FLOWCONTROL_NONE ); In manual mode, you must manually handle controlling signals from PC and reading flow control signals from by the device: RTS - Request To Send -- setRTS() method can used to set this CTS - Clear To Send -- isCTS() method can be used to read this For example, it is entirely possible to manually implement normal RTS/ CTS flow control with RXTX without relying on low-level automatic implementation. Mixed: You can also configure serial port to handle RTS/CTS automatically in only one direction, then you must set one of: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN ); or setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_OUT ); Then you can either ignore or implement manually the flow control scheme in the other direction. DTR and DSR: These are not officially flow control signals, but might affect external devices (disable, standby etc.). Use and meaning of these depends on the device. DTR - Data Terminal Ready -- setDTR() method DSR - Data Set Ready -- setDSR() method CTS/RTS standards: Please note that there are two standard ways RTS/CTS flow control is done (depends on the device): asymmetric (RS-232) symmetric (RS-232-E / TIA-232-E) For more info see: http://en.wikipedia.org/wiki/RS232#RTS.2FCTS_handshaking Some devices may even use RTS/CTS to some other non-standard purpose. With those devices, enabling automatic RTS/CTS could cause very strange behaviour as they clearly require manual control of CTS/RTS. ---- As far as I know, RXTX properly controls all these signals all the way to actual RS232 pins - unless there is a new platform incompatibility bug that I'm not aware of;) Mostly it's just wrong combination and/or usage of these additional signals that cause problems receiving or sending. And the only solution is to really *know* how your device wants these signals handled - and then code your RXTX application accordingly. Creating non-standard cable is not the right solution in my opinion. Unfortunately some applications (like HyperTerminal for example) might hit more or less accidentally to the right combination of RTS/CTS/DTR/ DSR usage and make RXTX look bad in comparison. While all RXTX does by default is - well - nothing. It gives full control the developer. -- I > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port >> Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I >> found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't >> look wrong >> to me. Am I looking at the right function or is the problem >> somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > > >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store >>> tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since >>> the old >>> cables aren't around anymore. The hardware's manual says nothing >>> except to >>> use a "Straight cable" but I figured that if it worked in >>> HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that >>> communicates with >>> the device (but doesn't do what I want, which is why I'm rolling >>> my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's >>> RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but >>> only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> > >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect >>>> to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your >>>> device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>>> (Sorry if this is a double post, but I sent my original message >>>>> without >>>>> subscribing, and since this is an urgent problem, I thought I'd >>>>> resend >>>>> after >>>>> subscribing to bypass the moderator limbo zone) >>>>> >>>>> Hi all, >>>>> >>>>> I've asked my question on StackOverflow already, so rather than >>>>> copy-paste >>>>> the question here, I'd like to redirect you there. >>>>> >>>>> Short version, I am no longer able to receive anything over >>>>> RS-232 with >>>>> RXTX, but other programs work fine. I'm definitely sending things, >>>>> because >>>>> when I connect with a different program, all the responses to the >>>>> commands I >>>>> sent via RXTX arrive all at once. >>>>> >>>>> Everything was fine in the spring, so what could have happened? >>>>> Windows >>>>> update? >>>>> >>>>> -Nate >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 06:11:11 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 15:11:11 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings Message-ID: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Hi, Summary: Patch includes multiple minor code quality improvements and also fixes one possible null pointer segfault on Mac. After this patch, compilation on Mac OS X is error/warning free even with gcc -Wall setting. I'll submit more code quality patches later that focus more on linux/ win/java. Fixes: Code quality: - First level parentheses around assignment used as while-loop truth value - Some printf formats not a string literals and including no format arguments Invalid null pointer usage: - Mac: IOMasterPort was called with (int)NULL which does not always resolve to segfault safe value. Corrected to use MACH_PORT_NULL instead. Patch: The patch is against CVS head (@2009/09/09). Attached patch file is in 'cvs diff -up' format. I'll commit this patch to the CVS later this week if there are no objections. Feel free to comment. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090909.patch Type: application/octet-stream Size: 1966 bytes Desc: not available URL: From m.j.tandy at warwick.ac.uk Wed Sep 9 06:57:55 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 13:57:55 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> OK, I just ran a test with my copy of RxTx and the following program: import gnu.io.*; public class SerialTest { public static void main(String[] args) { try { CommPortIdentifier portid = CommPortIdentifier.getPortIdentifier("COM9"); SerialPort serialPort = (SerialPort)portid.open("Serial port DTR/RTS test", 1000); serialPort.setSerialPortParams(4800, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.disableReceiveTimeout(); for (int i=0 ; i<60 ; i++) { serialPort.setDTR(true); serialPort.setRTS(true); Thread.sleep(1000); serialPort.setDTR(false); serialPort.setRTS(false); Thread.sleep(1000); } } catch (Exception e) { e.printStackTrace(); System.exit(1); } System.exit(0); } } I'm using a USB-serial converter (Prolific PL-2303) and I used a multimeter to check that my DTR and RTS pins were both toggling, and they were - between +7 and -6.4 volts. In other words, on the computer I'm using at the moment, with the version of RxTx I'm using at the moment, setDTR and setRTS both seem to work fine. I don't know if it's worth it for you to perform the same test. I gather there are several different configurations for hardware flow control, (DTR/DSR handshaking as well as RTS/CTS handshaking, handshaking for half-duplex operation, and similar) so the cable that worked for me might still be worth a try. 2009/9/9 Michael Tandy : > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong >> to me. Am I looking at the right function or is the problem somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since the old >>> cables aren't around anymore. The hardware's manual says nothing except to >>> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that communicates with >>> the device (but doesn't do what I want, which is why I'm rolling my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>> > (Sorry if this is a double post, but I sent my original message without >>>> > subscribing, and since this is an urgent problem, I thought I'd resend >>>> > after >>>> > subscribing to bypass the moderator limbo zone) >>>> > >>>> > Hi all, >>>> > >>>> > I've asked my question on StackOverflow already, so rather than >>>> > copy-paste >>>> > the question here, I'd like to redirect you there. >>>> > >>>> > Short version, I am no longer able to receive anything over RS-232 with >>>> > RXTX, but other programs work fine. I'm definitely sending things, >>>> > because >>>> > when I connect with a different program, all the responses to the >>>> > commands I >>>> > sent via RXTX arrive all at once. >>>> > >>>> > Everything was fine in the spring, so what could have happened? Windows >>>> > update? >>>> > >>>> > -Nate >>>> > >>>> > _______________________________________________ >>>> > Rxtx mailing list >>>> > Rxtx at qbang.org >>>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>>> > >>>> > >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > From david at attglobal.net Wed Sep 9 09:17:27 2009 From: david at attglobal.net (David Schmidt) Date: Wed, 09 Sep 2009 11:17:27 -0400 Subject: [Rxtx] 2.2 Release plans Message-ID: <4AA7C707.5060802@attglobal.net> I'm holding off releasing an update to my project (adtpro.sourceforge.net) to support OSX Snow Leopard because I'd like to ship an "official" build of rxtx 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for toggling a port off). CVS is looking great on OSX - thanks to all who have been hard at work on that. I wish there were just one more update - Pre3? :-) My question... If I wanted to make a release in, say, a week... would it pay to wait for rxtx, or should I plan to build and ship a local build of 2.2 out of CVS myself? - David Schmidt From tjarvi at qbang.org Wed Sep 9 19:14:29 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:14:29 -0600 (MDT) Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: On Wed, 9 Sep 2009, Ilkka Myller wrote: > Hi, > > Summary: > > Patch includes multiple minor code quality improvements and also fixes one > possible null pointer segfault on Mac. > After this patch, compilation on Mac OS X is error/warning free even with gcc > -Wall setting. > I'll submit more code quality patches later that focus more on > linux/win/java. > > Fixes: > > Code quality: > - First level parentheses around assignment used as while-loop truth value > - Some printf formats not a string literals and including no format arguments > > Invalid null pointer usage: > - Mac: IOMasterPort was called with (int)NULL which does not always resolve > to segfault safe value. Corrected to use MACH_PORT_NULL instead. > > Patch: > > The patch is against CVS head (@2009/09/09). > Attached patch file is in 'cvs diff -up' format. > > I'll commit this patch to the CVS later this week if there are no objections. > Feel free to comment. > These ifdefs can go. If you like I can remove them when you are done. #ifdef DEBUG_MW mexErrMsgTxt( msg ); #else They are just printf like debug messages for use in an environment in which I could not get directly to stderr/stdout. I don't think anyone uses them anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Sep 9 19:17:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:17:43 -0600 (MDT) Subject: [Rxtx] 2.2 Release plans In-Reply-To: <4AA7C707.5060802@attglobal.net> References: <4AA7C707.5060802@attglobal.net> Message-ID: On Wed, 9 Sep 2009, David Schmidt wrote: > I'm holding off releasing an update to my project (adtpro.sourceforge.net) to > support OSX Snow Leopard because I'd like to ship an "official" build of rxtx > 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for > toggling a port off). CVS is looking great on OSX - thanks to all who have > been hard at work on that. I wish there were just one more update - Pre3? > :-) > > My question... If I wanted to make a release in, say, a week... would it pay > to wait for rxtx, or should I plan to build and ship a local build of 2.2 out > of CVS myself? > Hi David, I would suggest planning on shipping a local build in a 1 week timeframe. We could put another prerelease up but there are still fixes coming in. -- Trent Jarvi tjarvi at qbang.org From ilkka at myller.com Wed Sep 9 23:07:34 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:07:34 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: <04A41559-598C-4B6E-821A-DA90CB6228E7@myller.com> Patch (im-20090909.patch) has been committed to the CVS. Trent: I'll include DEBUG_MW cleanup to my next patch. > > On Wed, 9 Sep 2009, Ilkka Myller wrote: > >> Hi, >> >> Summary: >> >> Patch includes multiple minor code quality improvements and also >> fixes one possible null pointer segfault on Mac. >> After this patch, compilation on Mac OS X is error/warning free >> even with gcc -Wall setting. >> I'll submit more code quality patches later that focus more on >> linux/win/java. >> >> Fixes: >> >> Code quality: >> - First level parentheses around assignment used as while-loop >> truth value >> - Some printf formats not a string literals and including no format >> arguments >> >> Invalid null pointer usage: >> - Mac: IOMasterPort was called with (int)NULL which does not always >> resolve to segfault safe value. Corrected to use MACH_PORT_NULL >> instead. >> >> Patch: >> >> The patch is against CVS head (@2009/09/09). >> Attached patch file is in 'cvs diff -up' format. >> >> I'll commit this patch to the CVS later this week if there are no >> objections. >> Feel free to comment. >> > > These ifdefs can go. If you like I can remove them when you are done. > > #ifdef DEBUG_MW > mexErrMsgTxt( msg ); > #else > > They are just printf like debug messages for use in an environment > in which I could not get directly to stderr/stdout. I don't think > anyone uses them anymore. > > -- > Trent Jarvi > tjarvi at qbang.org From ilkka at myller.com Wed Sep 9 23:35:13 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:35:13 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= Message-ID: Hi, Summary: Patch fixes compiling on Linux distributions/kernels that dont ship with linux/utsrelease.h header and therefore have no UTS_RELEASE defined. Usually this applies only to newer distributions and/or kernels - for example Ubuntu 9.04. Fixes: The UTS_RELEASE vs uname checking in initialization functions is now done only in debug build and only when UTS_RELEASE is actually defined. Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910.patch Type: application/octet-stream Size: 9542 bytes Desc: not available URL: From ilkka at myller.com Thu Sep 10 06:43:02 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 15:43:02 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= In-Reply-To: References: Message-ID: Patch has been committed to CVS. > Hi, > > Summary: > > Patch fixes compiling on Linux distributions/kernels that dont ship > with linux/utsrelease.h header and therefore have no UTS_RELEASE > defined. > Usually this applies only to newer distributions and/or kernels - > for example Ubuntu 9.04. > > Fixes: > > The UTS_RELEASE vs uname checking in initialization functions is now > done only in debug build and only when UTS_RELEASE is actually > defined. > > Patch: > > The patch is against CVS head (@2009/09/10). > Attached patch file is in 'cvs diff -up' format. > > > Thanks, > > -- > I > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Thu Sep 10 11:08:01 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 18:08:01 +0300 Subject: [Rxtx] [Patch] Remove unused MathWorks MATLAB DEBUG_MW ifdefs Message-ID: <6DB57DB1-A47E-4435-9CD6-212B671A2849@myller.com> Summary: Patch removes unused MathWorks MATLAB timing debug ifdefs (DEBUG_MW). This is a request from Trent. Fixes: - Removes DEBUG_MW definitions - Removes unused mex....() function definitions - Corrects DEBUG_TIMING to work properly without mexPrintf (with Mac OS X specific format string fixes included) - Removes unused/duplicate timeval struct and DEBUG_TIMING definitions from SerialImp.c and SerialImp.h - Corrects fprintf call in SerialImp.cpp Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910b.patch Type: application/octet-stream Size: 9841 bytes Desc: not available URL: From Kapil_Gupta at hcl.in Thu Sep 10 12:25:29 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 10 Sep 2009 21:55:29 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, I am getting some problem with RXTX on macintosh (reading some data from the device attached to the usb port through usb to serial mechanism). I used the RXTX 2.1.7 then I got PortInUseException but after using 2.2pre it worked fine. But it works only for the first time, it hangs in the second time while opening the port. Please find the attached code. This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Thu Sep 10 15:00:14 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 22:00:14 +0300 Subject: [Rxtx] [Patch] Implement return value checking to file I/O calls Message-ID: Summary: The return value of some functions should always be used. For example, it is dangerous to not check the return value of a write(), read(), open(), fscanf() calls. This patch fixes such occurences in RXTX code. For example: unchecked read() call could result in later - and often seemingly unrelated - segfault due to undefined read buffer contents. After this patch the Linux build process is error/warning free even with gcc -Wall -Werror. Fixes: - Implemented return value checking to file I/O calls in SerialImp.c:fhs_lock(), uucp_lock() and is_device_locked() functions. - Added error recovery for fuserImp.c fscanf() calls. Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910c.patch Type: application/octet-stream Size: 3370 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Thu Sep 10 15:08:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 22:08:05 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> Hi Kapil, I believe this issue has been fixed in CVS version, but still exists in 2.2pre2 available from RXTX wiki. For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html As you've seen from the recent patches announced on this list, we are working very hard to make a new 2.2pre(?) release available. Meanwhile, you can compile your own RXTX binaries from CVS source. On Mac it should be exceptionally easy with new Xcode 3.x project files. Thank you for your patience, -- I > > I am getting some problem with RXTX on macintosh (reading some data > from the device attached to the usb port through usb to serial > mechanism). I used the RXTX 2.1.7 then I got PortInUseException but > after using 2.2pre it worked fine. But it works only for the first > time, it hangs in the second time while opening the port. From ilkka at myller.com Fri Sep 11 06:07:22 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 13:07:22 +0300 Subject: [Rxtx] [Patch] Windows build improvements (MinGW32, MSVC and LCC) Message-ID: <81D06766-8D51-485A-B2A2-624C8EA690BA@myller.com> Summary: Fixes various compiler warnings with Windows builds. Removes unused code blocks from compilation. After this patch the Windows build process is error/warning free with MinGW32, MSVC and LCC compilers - even with -Wall enabled. Does not fix: Latest LCC compiler version still fails even after this patch due to compiler trap error. Trap error does not specify source code location - it fails outputting SerialImp.obj binary. Compiling SerialImp.c without binary output works. Could this be a bug in LCC? Tested with clean RXTX source, latest standard LCC installation and with both Windows Vista SP1 x86 and Windows XP SP3 x86. Patch: The patch is against CVS (@2009/09/11). Attached patch file is in 'cvs diff -up' format. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090911.patch Type: application/octet-stream Size: 6673 bytes Desc: not available URL: From tjarvi at qbang.org Tue Sep 1 02:38:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 1 Sep 2009 02:38:40 -0600 (MDT) Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks Ilkka The problem should be resolved (confirmed from two locations). I'll be trying to hunt down a Snow Leopard box tomorrow evening as well. On Tue, 1 Sep 2009, Ilkka Myller wrote: > Hi, > > CVS server is reachable, but when trying anonymous login it replies: > > " > Fatal error, aborting. > anonymous: no such system user > " > > It seems that the anonymous cvs account is not yet properly configured on the > new system. > > -- > I > >> On Mon, 31 Aug 2009, Trent Jarvi wrote: >> >> The server has been beemed to another location for those experiencing >> routing problems. >> >> in bash: >> >> export CVSROOT=:pserver:anonymous at qbang.org:2401/var/cvs/cvsroot >> cvs login (no passwd) >> cvs co -r commapi-0-0-1 rxtx-devel >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Tue Sep 1 03:05:59 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 12:05:59 +0300 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks, The new CVS server works well :) I can also confirm that latest CVS version builds properly with unmodified Snow Leopard (Mac OS X 10.6) system: Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 gcc version 4.2.1 (Apple Inc. build 5646) Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) --> Resulting JNI library (Universal Binary): i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = 9d15fc488b301da8bf65b2c9456a7bbb --> Resulting JAR: RXTXComm.jar / 60942 bytes MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 Atleast it builds.. and probably works too. I have not tested that yet. -- I Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > The problem should be resolved (confirmed from two locations). I'll > be trying to hunt down a Snow Leopard box tomorrow evening as well. From jimmy.lee at emotum.com Tue Sep 1 05:07:19 2009 From: jimmy.lee at emotum.com (Jimmy Lee [emotum]) Date: Tue, 1 Sep 2009 21:07:19 +1000 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: <112685a90909010407i6054acb5tc2b12196797bfaf1@mail.gmail.com> Could we access to the binaries? Please :) 2009/9/1 Ilkka Myller > Thanks, > > The new CVS server works well :) > > I can also confirm that latest CVS version builds properly with unmodified > Snow Leopard (Mac OS X 10.6) system: > > Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_I386 i386 > gcc version 4.2.1 (Apple Inc. build 5646) > Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) > > > --> Resulting JNI library (Universal Binary): > > i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes > > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 > librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc > > MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = > 9d15fc488b301da8bf65b2c9456a7bbb > > > --> Resulting JAR: > > RXTXComm.jar / 60942 bytes > > MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 > > > > Atleast it builds.. and probably works too. I have not tested that yet. > > -- > I > > Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > > The problem should be resolved (confirmed from two locations). I'll be >> trying to hunt down a Snow Leopard box tomorrow evening as well. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Tue Sep 1 06:21:28 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Tue, 1 Sep 2009 08:21:28 -0400 (EDT) Subject: [Rxtx] Snow Leopard binaries Message-ID: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> +1 for binaries - pretty please with sugar on top... -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com From fredm at alum.mit.edu Tue Sep 1 06:24:17 2009 From: fredm at alum.mit.edu (Fred G. Martin) Date: Tue, 1 Sep 2009 08:24:17 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> Message-ID: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> You can find one here: http://iharder.sourceforge.net/current/java/ Also, you need to add yourself (any rxtx user) to the uucp group. Niutils don't exist, but dscl is a replacement. There is info for using it here: http://aplawrence.com/MacOSX/directory_services.html Fred On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Tue Sep 1 07:03:37 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Tue, 1 Sep 2009 18:33:37 +0530 Subject: [Rxtx] Help for RXTX on mac Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time I am able to read the device but on second time, it hangs on COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then it was showing the PortInUseException, I replaced the RXTX library to 2.2Pre1 so it is showing this problem. Is this is a problem with RXTX on Mac? Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: From ilkka at myller.com Tue Sep 1 07:57:06 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 16:57:06 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:02:31 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:02:31 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:43:49 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:43:49 +0300 Subject: [Rxtx] Help for RXTX on mac In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE@myller.com> Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Arseneau at Sun.COM Tue Sep 1 08:51:32 2009 From: Eric.Arseneau at Sun.COM (Eric Arseneau) Date: Tue, 01 Sep 2009 07:51:32 -0700 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24@sun.com> Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 09:24:30 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 18:24:30 +0300 Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D@myller.com> Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Thu Sep 3 02:50:16 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Thu, 3 Sep 2009 10:50:16 +0200 Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s From Kapil_Gupta at hcl.in Thu Sep 3 06:52:21 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:22:21 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From Kapil_Gupta at hcl.in Thu Sep 3 07:15:19 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:45:19 +0530 Subject: [Rxtx] Rxtx Digest, Vol 25, Issue 3 In-Reply-To: References: Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C50BB@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi myller, I have attached the code with the mail. Please help me if I am doing something wrong in it. Thanks & Regards, Kapil Gupta -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of rxtx-request at qbang.org Sent: Thursday, September 03, 2009 4:15 PM To: rxtx at qbang.org Subject: Rxtx Digest, Vol 25, Issue 3 Send Rxtx mailing list submissions to rxtx at qbang.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qbang.org/mailman/listinfo/rxtx or, via email, send a message with subject or body 'help' to rxtx-request at qbang.org You can reach the person managing the list at rxtx-owner at qbang.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Rxtx digest..." Today's Topics: 1. Re: Snow Leopard binaries (Ilkka Myller) 2. Re: Snow Leopard binaries (Ilkka Myller) 3. Re: Help for RXTX on mac (Ilkka Myller) 4. Re: Snow Leopard binaries (Eric Arseneau) 5. Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters (Ilkka Myller) 6. RXTX multiple crashes (Kjetil ?ster?s) 7. RXTX 2.2Pre + MacMini+ Deadlock while second time port open (Kapil Gupta) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Sep 2009 16:57:06 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 1 Sep 2009 17:02:31 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <55EC133D-DC83-45A3-849C-02714904D580 at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 1 Sep 2009 17:43:49 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Help for RXTX on mac Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Tue, 01 Sep 2009 07:51:32 -0700 From: Eric Arseneau Cc: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24 at sun.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 1 Sep 2009 18:24:30 +0300 From: Ilkka Myller To: rxtx Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Thu, 3 Sep 2009 10:50:16 +0200 From: Kjetil ?ster?s To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s ------------------------------ Message: 7 Date: Thu, 3 Sep 2009 18:22:21 +0530 From: Kapil Gupta To: "rxtx at qbang.org" Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059 at NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset="us-ascii" Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: ------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx End of Rxtx Digest, Vol 25, Issue 3 *********************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From ilkka at myller.com Thu Sep 3 11:17:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 3 Sep 2009 20:17:27 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <4520677F-E8F0-46F5-B4AD-3AD3A7C2AED3@myller.com> Hi Kapil, The code is incomplete and I did not find anything I could to test/ debug with this. I also tried to find the actual serial port opening, but found only a call to missing method which creates the SerialPort object (?): serialPort = getSerialPortConnection( COMPort, this.readEvent.getDeviceName(), SerialCommConfig.DEVICE1[SerialCommConfig.TIMEOUT], SerialCommConfig.DEVICE1[SerialCommConfig.BAUDRATE], SerialCommConfig.DEVICE1[SerialCommConfig.DATABITS], SerialCommConfig.DEVICE1[SerialCommConfig.STOPBITS], SerialCommConfig.DEVICE1[SerialCommConfig.PARITY] ); The class SerialCommConfig is missing too. If this is a part of the actual code you are using, please note that you are not actually closing the serial port. The call to close() method is commented out: try { // serialPort.close(); } catch (Exception ex) { ex.printStackTrace(); } Re-opening of the serial port wont work if you haven't properly closed it first. -- I > > I am using RXTX on Macintosh to communicate to my device. First time > the device responds well but on second time, it hangs on > COMPort.open (name, timeout). > > I have attached the source code in a file. Please help me. > > Thanks & Best Regards, > Kapil -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorton at intellimec.com Thu Sep 3 11:37:55 2009 From: dmorton at intellimec.com (Daniel Morton) Date: Thu, 3 Sep 2009 13:37:55 -0400 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. (I haven't tried previous version though). Daniel Morton Java/J2EE Developer Tel +1 519.745.8887 x4331 Email dmorton at intellimec.com www.intellimec.com | www.iLane.com | www.drivesync.com Intelligent Mechatronic Systems Inc. 435 King Street North Waterloo, ON N2J 2Z5 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s Sent: Thursday, September 03, 2009 4:50 AM To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. From alexanderkiel at gmx.net Fri Sep 4 02:29:15 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 10:29:15 +0200 Subject: [Rxtx] Official Javadoc Location Message-ID: <1252052955.4025.80.camel@T61-KIEL> Hi List, I wasn't able to find an official location of RXTX Javadoc accessible over HTTP. Maybe someone can link me to it. If there is no such location, I would like to see one. I like to link from my own Javadoc to such a location. Thanks Alexander - e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:19:25 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:19:25 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> Message-ID: <1252055965.4025.84.camel@T61-KIEL> Hi Michael, thanks for the pointer. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 09:48 +0100, Michael Tandy wrote: > RxTx javadoc: http://users.frii.com/jarvi/rxtx/doc/index.html > Javax interface RxTx duplicates javadoc: > http://java.sun.com/products/javacomm/reference/api/index.html > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:22:14 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:22:14 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> Message-ID: <1252056134.4025.87.camel@T61-KIEL> Hi Eike, thanks, but I need a direct package pointer so that Javadoc will link the gnu.io packages automatically to the right location. Michael has pointed me to http://users.frii.com/jarvi/rxtx/doc/index.html which has the gnu.io packages. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 11:04 +0200, Eike Hinderk J?rrens wrote: > Hi Alexander, > it seems to me that RXTX is implementing this API: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Kind regards, > Eike > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kjetilos at gmail.com Fri Sep 4 03:43:41 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 11:43:41 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> Message-ID: <7a803d460909040243ke4449ecucbe2cd8b15761746@mail.gmail.com> Hi Daniel, This is interesting, what type of application are you making? Is there a lot of signaling on different COM ports at the same time in your application? In our application we have 11 devices connected to different COM ports, 9 of these are in active use when the application is running. I'm wondering how to use the RXTX library version 2.1.7 in this scenario without causing it to crash. After adding more signaling on the COM ports in our application we have now experienced other crashes and it is natural to think that it has something to do with our way of using RXTX from several threads at the same time. So my question is are there any methods like read/write/flush/close that are not thread safe and should be handled with care? And similarly is the RXTXPort.SerialInputStream and RXTXPort.SerialOutputStream thread safe? 2009/9/3 Daniel Morton : > I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. ?(I haven't tried previous version though). > > Daniel Morton > Java/J2EE Developer > > Tel ? ?+1 519.745.8887 x4331 > Email ? ?dmorton at intellimec.com > > > www.intellimec.com ?| ?www.iLane.com ?| ?www.drivesync.com > > > > Intelligent Mechatronic Systems Inc. > 435 King Street North Waterloo, ON N2J 2Z5 > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s > Sent: Thursday, September 03, 2009 4:50 AM > To: rxtx at qbang.org > Subject: [Rxtx] RXTX multiple crashes > > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x7d0d] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0ce75800): ?JavaThread "Y Worker" daemon > [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 > > Registers: > EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 > ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 > EIP=0x10007d0d, EFLAGS=0x00010202 > > Top of Stack: (sp=0x0d7ff6d8) > 0x0d7ff6d8: ? 0d7ff700 00000000 00000000 00000000 > 0x0d7ff6e8: ? 02a2eae8 00000123 00002958 0d7ff718 > 0x0d7ff6f8: ? 7c830887 7c90d28a 7c8664b5 00000e2c > 0x0d7ff708: ? 00002958 00000000 00000000 7c90cffa > 0x0d7ff718: ? 7c809bdb 00002958 0d7ff758 00000e40 > 0x0d7ff728: ? 00002958 02bd0468 0ce75800 080e4ee0 > 0x0d7ff738: ? 00000000 00000000 00000000 00000000 > 0x0d7ff748: ? 00000000 00000000 00000014 7c90d09a > > Instructions: (pc=0x10007d0d) > 0x10007cfd: ? 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 > 0x10007d0d: ? 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 > > > Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x7d0d] > J ?gnu.io.RXTXPort.nativeDrain(Z)Z > J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > ... > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x9c55] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0cddf400): ?JavaThread "XXX Worker" daemon > [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 > > Registers: > EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 > ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 > EIP=0x10009c55, EFLAGS=0x00010206 > > Top of Stack: (sp=0x0bb8f830) > 0x0bb8f830: ? 00000000 00000000 c0000005 00000000 > 0x0bb8f840: ? 00000000 00f1f0a5 00000002 00000000 > 0x0bb8f850: ? 003a0100 0001003f 0bb8fb20 0b9ff918 > 0x0bb8f860: ? 00000000 00000000 0bb8fb68 0bb8fb20 > 0x0bb8f870: ? 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 > 0x0bb8f880: ? 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 > 0x0bb8f890: ? 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 > 0x0bb8f8a0: ? 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 > > Instructions: (pc=0x10009c55) > 0x10009c45: ? 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff > 0x10009c55: ? 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 > > > Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x9c55] > C ?[rxtxSerial.dll+0xa05e] > J ?gnu.io.RXTXPort.readByte()I > J ?gnu.io.RXTXPort$SerialInputStream.read()I > J ?java.io.FilterInputStream.read()I > ... > > -- > Kjetil ?ster?s > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kjetil ?ster?s From tjarvi at qbang.org Fri Sep 4 06:00:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Sep 2009 06:00:40 -0600 (MDT) Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x7d0d] > J gnu.io.RXTXPort.nativeDrain(Z)Z > J gnu.io.RXTXPort$SerialOutputStream.flush()V > Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x9c55] > C [rxtxSerial.dll+0xa05e] > J gnu.io.RXTXPort.readByte()I > J gnu.io.RXTXPort$SerialInputStream.read()I RXTX 2.1-7 has concurrency issues that will show upon multicore systems. These should be resolved in the 2.2 pre release. A user application could synchronize the read/write/open/close calls while using 2.1 to avoid the concurrency issue. The flush is probably following a write while the readByte is coming from read(byte b). The bugs existed in rxtx for a long time. I assume changes in the JVM and the presence of multicore systems exposed the issues. -- Trent Jarvi tjarvi at qbang.org From kjetilos at gmail.com Fri Sep 4 06:33:33 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 14:33:33 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <7a803d460909040533n1caf240y8168477a578bc45c@mail.gmail.com> Den 4. september 2009 14.00 skrev Trent Jarvi f?lgende: > > > On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > >> Hi >> >> We are using RXTX version 2.1.7 actively and lately we are having some >> issues with the RXTX library crashing. We are running a windows xp >> system with multiple COM ports where each COM port have a serial >> device connected. Lately we have increased the amount of signaling >> done over the COM ports and we are experiencing several odd crashes. I >> tried to search the mailinglist for something similar but was unable >> to find anything. At one time the RXTX crashed in the >> gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the >> gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack >> traces if someone is interested in having a look. Has anyone seen the >> same crashes? and does anyone know what can cause such crash? >> >> >> Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x7d0d] >> J ?gnu.io.RXTXPort.nativeDrain(Z)Z >> J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > >> Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x9c55] >> C ?[rxtxSerial.dll+0xa05e] >> J ?gnu.io.RXTXPort.readByte()I >> J ?gnu.io.RXTXPort$SerialInputStream.read()I > > > RXTX 2.1-7 has concurrency issues that will show upon multicore systems. > These should be resolved in the 2.2 pre release. ?A user application could > synchronize the read/write/open/close calls while using 2.1 to avoid the > concurrency issue. > > The flush is probably following a write while the readByte is coming from > read(byte b). > > The bugs existed in rxtx for a long time. ?I assume changes in the JVM and > the presence of multicore systems exposed the issues. > Ok, so we should look more into using a newer version of RXTX. The current version from the webpage is 2.2pre2, what is the stability status of this version. Is it good enough for use in a production environment? -- Kjetil ?ster?s From martinezrodolfo at gmail.com Fri Sep 4 13:39:57 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Fri, 4 Sep 2009 15:09:57 -0430 Subject: [Rxtx] Problem with data available event Message-ID: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Hello list members. I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a serial port USB adapter to communicate with an electronical inmunoassay analyzer. The program works porperly with one model of the analyzer series. It defines a protocol which every message sent should be replied with an ACK in order to continue with the communication. Now we are trying to communicate with another model of the same brand and series wich in theory should be much of the same of what was previously done. Unfortunately, that is not the case. The problem with this connection is that it never fires the Data Available serial port event. Is like if nothing was being received in the input stream. The following code always prints zero when the equipment should be transmitting. ----------------------- beginning of sample code ---------------------------------- SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", 10000); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); int len = 0; byte[] readBuffer = new byte[8]; while (true) { len = in.read(readBuffer); System.out.println(len); writer.writeACK(); // writing ACK to analyzer } ----------------------- end of sample code ------------------------------------------ We know that the analyzer is transmitting because HyperTerminal does shows the proper output. In fact, after running the above code and connecting via Hyperterminal all data is received in one block. Is like the data sent from the analyzer is being held somewhere in the way. Sniffing at the serial port, noticed that IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this helps to find what might be wrong or not, but here they are: On Hyperterminal: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 XonLimit:80 XoffLimit:200 On Java: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 XonLimit:0 XoffLimit:0 Thanks in advance for your help. Rodolfo M From ilkka at myller.com Sat Sep 5 04:36:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 5 Sep 2009 13:36:27 +0300 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <121198EE-65A4-463B-ACC7-29FFB9855B2C@myller.com> Hi Rodolfo, By default RXTX does not enable any flow control for the serial port. Please check what flow control you have active in HyperTerminal when you are able to receive data and then use the same flow control with RXTX serial port: serialPort.setFlowControlMode(int flowcontrol); Possible flowcontrol flags are (from SerialPort class) FLOWCONTROL_NONE FLOWCONTROL_RTSCTS_IN FLOWCONTROL_RTSCTS_OUT FLOWCONTROL_XONXOFF_IN FLOWCONTROL_XONXOFF_OUT For example, you can try enabling RTS/CTS hardware flow control. Note the bitwise OR operator ' | ': serialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Also if your device requires RTS/CTS flow control make sure you have fully connected serial cable (not just RX, TX, GND for example, but also RTS, CTS, DTR). One thing you might want to check is the state of DTR (Data Terminal Ready). Some devices wait for the DTR signal before they send any data. You can enable or disable DTR signal (high/low) with: serialPort.setDTR( boolean state ); -- I > Hello list members. > > I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a > serial port USB adapter to communicate with an electronical > inmunoassay analyzer. The program works porperly with one model of the > analyzer series. It defines a protocol which every message sent should > be replied with an ACK in order to continue with the communication. > Now we are trying to communicate with another model of the same brand > and series wich in theory should be much of the same of what was > previously done. Unfortunately, that is not the case. The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. > > ----------------------- beginning of sample code > ---------------------------------- > SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", > 10000); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > InputStream in = serialPort.getInputStream(); > OutputStream out = serialPort.getOutputStream(); > > int len = 0; > byte[] readBuffer = new byte[8]; > while (true) { > len = in.read(readBuffer); > System.out.println(len); > > writer.writeACK(); // writing ACK to analyzer > } > ----------------------- end of sample code > ------------------------------------------ > > We know that the analyzer is transmitting because HyperTerminal does > shows the proper output. In fact, after running the above code and > connecting via Hyperterminal all data is received in one block. Is > like the data sent from the analyzer is being held somewhere in the > way. Sniffing at the serial port, noticed that > IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this > helps to find what might be wrong or not, but here they are: > > On Hyperterminal: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 > XonLimit:80 XoffLimit:200 > > On Java: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 > XonLimit:0 XoffLimit:0 > > > Thanks in advance for your help. > Rodolfo M > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.weber99 at gmx.net Sun Sep 6 13:51:12 2009 From: karl.weber99 at gmx.net (Karl Weber) Date: Sun, 6 Sep 2009 21:51:12 +0200 Subject: [Rxtx] Cannot create lock file Message-ID: <200909062151.12228.karl.weber99@gmx.net> Hi, I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an opensuse repository as well as from the homepage of the rxtx project. I have already added the user to the group uucp, however, it does not have any effect. What else do I have to do to make it work? (It does work with user root, though.) The error message is: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL Thanks in advance, Karl From tjarvi at qbang.org Sun Sep 6 13:51:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 6 Sep 2009 13:51:42 -0600 (MDT) Subject: [Rxtx] Cannot create lock file In-Reply-To: <200909062151.12228.karl.weber99@gmx.net> References: <200909062151.12228.karl.weber99@gmx.net> Message-ID: On Sun, 6 Sep 2009, Karl Weber wrote: > Hi, > > I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an > opensuse repository as well as from the homepage of the rxtx project. > > I have already added the user to the group uucp, however, it does not have > any effect. What else do I have to do to make it work? (It does work with > user root, though.) > > The error message is: > > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to > create lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > > Thanks in advance, Karl Look at the group that owns /var/lock with ls -ld /var/lock The following should work as a user when they are in the correct group: touch /var/lock/test && rm -f /var/lock/test -- Trent Jarvi tjarvi at qbang.org From Luca.Catoni at sysdat.it Mon Sep 7 06:32:42 2009 From: Luca.Catoni at sysdat.it (Luca Catoni) Date: Mon, 7 Sep 2009 14:32:42 +0200 Subject: [Rxtx] time-out implementation Message-ID: I need to implement a simple timer class to manage time-out in my RS-232 serial communication with a remote device using the rxtx library. The functions that the timer should have are start(), and reset() and start() method must throw an exception (TimeoutException) when it expires. I am not an expert in concurrent programming and I do not have much knowledge on threads. myTimer.setExpirationTime(myvalue); ? public void serialEvent(SerialPortEvent event) { if (event.getEventType() == SerialPortEvent.OUTPUT_BUFFER_EMPTY) { // transmission ? out.write(?); try{ myTimer.start(); }catch(TimeoutException te){ myTimer.reset(); ? } ? if (event.getEventType() == SerialPortEvent.DATA_AVAILABLE) { // receiving in.read(?); if (mycondition){ myTimer.stop();//ok, timer NOT expired myTimer.reset();//now I can call start() method again in //transmission to restart my timer when I //have to transmit next data } Can anyone help me to implement the class MyTimer? thanks in advance. -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Mon Sep 7 06:49:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Mon, 7 Sep 2009 18:19:24 +0530 Subject: [Rxtx] 2.2Pre + MacMini+ Deadlock while second time port Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E22FB6F@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, Please find the updated code (close call was commented by mistake). This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From michael.erskine at ketech.com Mon Sep 7 09:13:03 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 7 Sep 2009 16:13:03 +0100 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Rodolfo Mart?nez > Subject: [Rxtx] Problem with data available event > The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. Hi Rodolfo, The sample code you provided doesn't implement or register any event listeners. Regards, Michael Erskine. From martinezrodolfo at gmail.com Mon Sep 7 10:21:22 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Mon, 7 Sep 2009 11:51:22 -0430 Subject: [Rxtx] Problem with data available event In-Reply-To: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> Message-ID: <30eacee0909070921l7f285765ue2c661963183fd2b@mail.gmail.com> On Mon, Sep 7, 2009 at 10:43 AM, Michael Erskine wrote: > Hi Rodolfo, > The sample code you provided doesn't implement or register any event listeners. > > Regards, > Michael Erskine. Hi Michael, I didn't write the event listeners declaration on the sample code for simplicity, but I do implement them on my real code. I should have mentioned it on the sample code anyway... my bad. I haven't had access to the device I'm trying to connect, but tomorrow will. And hope that with the explanation of Ilkka Myller will succeed this time. Thanks for your attention. Rodolfo M From ajmas at sympatico.ca Mon Sep 7 16:58:13 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 7 Sep 2009 18:58:13 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" I noticed in the page you posted posted you indicated that you patched two files. Did you submit the changes to Jarvi, so they could be included in the main code branch? Andr? From tjarvi at qbang.org Mon Sep 7 16:57:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Sep 2009 16:57:53 -0600 (MDT) Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On Mon, 7 Sep 2009, Andre-John Mas wrote: > > On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > >> Sorry, my rudeness was not intentional (a typo). >> Lets try again.. ;) >> >> "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > I noticed in the page you posted posted you indicated that you patched two > files. Did you submit the changes to Jarvi, so they could be included in the > main code branch? > Hi Andr? Ilkka is working with us to get changes in. I'm not sure about those two patches which may already be in CVS. I'll let him answer that. I've given him write access to CVS and asked him to cc the list non whitespace changes when they are ready. Right now he is asking questions off the list regarding cleaning up the Mac and w32 build files. -- Trent Jarvi tjarvi at qbang.org From nsp25 at cornell.edu Mon Sep 7 21:17:45 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Mon, 7 Sep 2009 23:17:45 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: (Sorry if this is a double post, but I sent my original message without subscribing, and since this is an urgent problem, I thought I'd resend after subscribing to bypass the moderator limbo zone) Hi all, I've asked my question on StackOverflow already, so rather than copy-paste the question here, I'd like to redirect you there . Short version, I am no longer able to receive anything over RS-232 with RXTX, but other programs work fine. I'm definitely sending things, because when I connect with a different program, all the responses to the commands I sent via RXTX arrive all at once. Everything was fine in the spring, so what could have happened? Windows update? -Nate -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.j.tandy at warwick.ac.uk Tue Sep 8 01:30:48 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Tue, 8 Sep 2009 08:30:48 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> OK, so: 1. It worked in spring but has stopped doing so and 2. The data all arrives at once when you start hyperterminal. Is it possible you're using a different serial cable to connect to the device, compared to the one you were using in spring? If so, the issue might be hardware flow control - that is, your device might be buffering data because it can't transmit it until your computer sets 'DTR' or 'RTS' or something like that. One way of bypassing hardware flow control is by using cables which cross over certain wires so that the right signals are always being sent; it's possible your old cable had these connections but your current cable doesn't have them. If you can find the old cable, you could put it back in and see if that fixes things? 2009/9/8 Nathaniel S. Parsons : > (Sorry if this is a double post, but I sent my original message without > subscribing, and since this is an urgent problem, I thought I'd resend after > subscribing to bypass the moderator limbo zone) > > Hi all, > > I've asked my question on StackOverflow already, so rather than copy-paste > the question here, I'd like to redirect you there. > > Short version, I am no longer able to receive anything over RS-232 with > RXTX, but other programs work fine. I'm definitely sending things, because > when I connect with a different program, all the responses to the commands I > sent via RXTX arrive all at once. > > Everything was fine in the spring, so what could have happened? Windows > update? > > -Nate > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Tue Sep 8 01:50:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 8 Sep 2009 10:50:33 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <111FEC9A-26BA-435C-BABC-314C7E4F23E5@myller.com> Hi all, Patches applied to the 2.1.7 binaries distributed by Robert Harder (http://iharder.sourceforge.net/current/java/ ) are already in the 2.2. Actually in 2.2 the issue with integer types handling seems to be fixed even more extensively than that single patch to 2.1.7 originally did. And yes, Trent has granted me CVS commit access. Thank you. First thing I'm going to focus on is the code quality and clean up: unused variables, invalid pointer usage etc.. Most of this just causing compile warnings - some harmless and some have potential for causing runtime problems. Instead of just blindly committing new changes to CVS, I've been discussing with Trent about the way things have been done in the RXTX CVS before. (how to handle white space patches, what needs to be discussed with the list first, proper locations for new files/ directories/subprojects, "the way things are done in RXTX"). But patches are coming and bugs will be fixed. I hope everyone will continue to submit the bugs they discover to this mailing list. Most important thing is to provide enough info (code;) so that the issue can be duplicated and eventually fixed. -- I > > > On Mon, 7 Sep 2009, Andre-John Mas wrote: >> >> I noticed in the page you posted posted you indicated that you >> patched two files. Did you submit the changes to Jarvi, so they >> could be included in the main code branch? >> > > Ilkka is working with us to get changes in. I'm not sure about > those two patches which may already be in CVS. I'll let him answer > that. > > I've given him write access to CVS and asked him to cc the list non > whitespace changes when they are ready. Right now he is asking > questions off the list regarding cleaning up the Mac and w32 build > files. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 15:35:19 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 17:35:19 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: Thanks for the response. I'll try to get to the electronics store tomorrow to get more serial cables, even if it isn't the problem. I am using a different serial cable than I was in the spring. It's actually a Male/Female cable with a female-female adapter since the old cables aren't around anymore. The hardware's manual says nothing except to use a "Straight cable" but I figured that if it worked in HyperTerminal, it should work in RXTX, right? Anyways, I've also noticed some things that are different between HyperTerminal, RXTX, and a separate program I found that communicates with the device (but doesn't do what I want, which is why I'm rolling my own program) HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and DTR indicators are green Other program - not sure what settings it thinks it's using, but only SPM's RTS indicator is green RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators are on. >From Serial Port Monitor's help files (paraphrased): the indicators display the state of the serial control lines RTS - Request To Send CTS - Clear To Send DTR - Data Terminal Ready Could this be related to the problem? -Nate On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > OK, so: > > 1. It worked in spring but has stopped doing so and > 2. The data all arrives at once when you start hyperterminal. > > Is it possible you're using a different serial cable to connect to the > device, compared to the one you were using in spring? > > If so, the issue might be hardware flow control - that is, your device > might be buffering data because it can't transmit it until your > computer sets 'DTR' or 'RTS' or something like that. > > One way of bypassing hardware flow control is by using cables which > cross over certain wires so that the right signals are always being > sent; it's possible your old cable had these connections but your > current cable doesn't have them. If you can find the old cable, you > could put it back in and see if that fixes things? > > > 2009/9/8 Nathaniel S. Parsons : > > (Sorry if this is a double post, but I sent my original message without > > subscribing, and since this is an urgent problem, I thought I'd resend > after > > subscribing to bypass the moderator limbo zone) > > > > Hi all, > > > > I've asked my question on StackOverflow already, so rather than > copy-paste > > the question here, I'd like to redirect you there. > > > > Short version, I am no longer able to receive anything over RS-232 with > > RXTX, but other programs work fine. I'm definitely sending things, > because > > when I connect with a different program, all the responses to the > commands I > > sent via RXTX arrive all at once. > > > > Everything was fine in the spring, so what could have happened? Windows > > update? > > > > -Nate > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 18:57:58 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 20:57:58 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: I added a call to setRTS() but nothing changed in Serial Port Monitor, no matter what the argument was. Is this a bug, or did I call the wrong function? I tried to find the c code behind this function, and I think I found it in rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong to me. Am I looking at the right function or is the problem somewhere else? -Nate On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons wrote: > Thanks for the response. I'll try to get to the electronics store tomorrow > to get more serial cables, even if it isn't the problem. > > I am using a different serial cable than I was in the spring. It's actually > a Male/Female cable with a female-female adapter since the old cables aren't > around anymore. The hardware's manual says nothing except to use a "Straight > cable" but I figured that if it worked in HyperTerminal, it should work in > RXTX, right? > > Anyways, I've also noticed some things that are different between > HyperTerminal, RXTX, and a separate program I found that communicates with > the device (but doesn't do what I want, which is why I'm rolling my own > program) > > HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and > DTR indicators are green > Other program - not sure what settings it thinks it's using, but only SPM's > RTS indicator is green > RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators > are on. > > From Serial Port Monitor's help files (paraphrased): the indicators display > the state of the serial control lines > > RTS - Request To Send > CTS - Clear To Send > DTR - Data Terminal Ready > > Could this be related to the problem? > > -Nate > > > On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > >> OK, so: >> >> 1. It worked in spring but has stopped doing so and >> 2. The data all arrives at once when you start hyperterminal. >> >> Is it possible you're using a different serial cable to connect to the >> device, compared to the one you were using in spring? >> >> If so, the issue might be hardware flow control - that is, your device >> might be buffering data because it can't transmit it until your >> computer sets 'DTR' or 'RTS' or something like that. >> >> One way of bypassing hardware flow control is by using cables which >> cross over certain wires so that the right signals are always being >> sent; it's possible your old cable had these connections but your >> current cable doesn't have them. If you can find the old cable, you >> could put it back in and see if that fixes things? >> >> >> 2009/9/8 Nathaniel S. Parsons : >> > (Sorry if this is a double post, but I sent my original message without >> > subscribing, and since this is an urgent problem, I thought I'd resend >> after >> > subscribing to bypass the moderator limbo zone) >> > >> > Hi all, >> > >> > I've asked my question on StackOverflow already, so rather than >> copy-paste >> > the question here, I'd like to redirect you there. >> > >> > Short version, I am no longer able to receive anything over RS-232 with >> > RXTX, but other programs work fine. I'm definitely sending things, >> because >> > when I connect with a different program, all the responses to the >> commands I >> > sent via RXTX arrive all at once. >> > >> > Everything was fine in the spring, so what could have happened? Windows >> > update? >> > >> > -Nate >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Tue Sep 8 21:54:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 21:54:26 -0600 (MDT) Subject: [Rxtx] rxtx is moving to the clouds Message-ID: rxtx is moving onto a cloud server. You may notice short outages as things move around. So far the following is done. http://rxtx.qbang.org (will redirect rxtx.org there for 2.2) http://bugzilla.qbang.org (bugs) The mail-list is tomorrow night. CVS and FTP will be last. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 8 22:03:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 22:03:26 -0600 (MDT) Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: On Tue, 8 Sep 2009, Nathaniel S. Parsons wrote: > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? Hi Nathaniel, That depends upon what you are running. WinCE is for embedded windows. The Windows source is in src/termios.c (called from src/SerialImp.c). -- Trent Jarvi tjarvi at qbang.org From m.j.tandy at warwick.ac.uk Wed Sep 9 03:27:10 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 10:27:10 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> I had a similar problem a while ago - hardware that would work with Hyperterminal but not with Rxtx. I don't know if this is a bug in RxTx or not - I tried to find where in the RxTx source code those functions are actually implemented - I got as far as the ioctl function in termios.c, where the TIOCMSET case sets the MSR byte in the termios struct, but I can't figure out where that gets written to the dcb struct's fDtrControl dword. It could be a bug, or it could just be me missing something. In any case, at the time I had this problem I wasn't equipped to debug RxTx so instead I created a special cable to satisfy the hardware's flow control while leaving the data connection straight through. Here's how I connected it: At the female end of the cable (i.e. the hardware I was connecting to) I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. I connected the ground and data pins straight through - that is, pin 5 female end to pin 5 male end, pin 2 female end to pin 2 male end, pin 3 female end to pin 3 male end. Anyway, using that cable bypassed the hardware's flow control, and got RxTx working just as well as HyperTerminal - although I slowed down my communication to make sure I didn't encounter a situation where the flow control would have come into effect, as I had bypassed it! Hope that helps. 2009/9/9 Nathaniel S. Parsons : > I added a call to setRTS() but nothing changed in Serial Port Monitor, no > matter what the argument was. Is this a bug, or did I call the wrong > function? > > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? > > -Nate > > On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > wrote: >> >> Thanks for the response. I'll try to get to the electronics store tomorrow >> to get more serial cables, even if it isn't the problem. >> >> I am using a different serial cable than I was in the spring. It's >> actually a Male/Female cable with a female-female adapter since the old >> cables aren't around anymore. The hardware's manual says nothing except to >> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >> should work in RXTX, right? >> >> Anyways, I've also noticed some things that are different between >> HyperTerminal, RXTX, and a separate program I found that communicates with >> the device (but doesn't do what I want, which is why I'm rolling my own >> program) >> >> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >> DTR indicators are green >> Other program - not sure what settings it thinks it's using, but only >> SPM's RTS indicator is green >> RXTX - no matter what flow control I set, only SPM's CTS and DTR >> indicators are on. >> >> From Serial Port Monitor's help files (paraphrased): the indicators >> display the state of the serial control lines >> >> RTS - Request To Send >> CTS - Clear To Send >> DTR - Data Terminal Ready >> >> Could this be related to the problem? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> wrote: >>> >>> OK, so: >>> >>> 1. It worked in spring but has stopped doing so and >>> 2. The data all arrives at once when you start hyperterminal. >>> >>> Is it possible you're using a different serial cable to connect to the >>> device, compared to the one you were using in spring? >>> >>> If so, the issue might be hardware flow control - that is, your device >>> might be buffering data because it can't transmit it until your >>> computer sets 'DTR' or 'RTS' or something like that. >>> >>> One way of bypassing hardware flow control is by using cables which >>> cross over certain wires so that the right signals are always being >>> sent; it's possible your old cable had these connections but your >>> current cable doesn't have them. If you can find the old cable, you >>> could put it back in and see if that fixes things? >>> >>> >>> 2009/9/8 Nathaniel S. Parsons : >>> > (Sorry if this is a double post, but I sent my original message without >>> > subscribing, and since this is an urgent problem, I thought I'd resend >>> > after >>> > subscribing to bypass the moderator limbo zone) >>> > >>> > Hi all, >>> > >>> > I've asked my question on StackOverflow already, so rather than >>> > copy-paste >>> > the question here, I'd like to redirect you there. >>> > >>> > Short version, I am no longer able to receive anything over RS-232 with >>> > RXTX, but other programs work fine. I'm definitely sending things, >>> > because >>> > when I connect with a different program, all the responses to the >>> > commands I >>> > sent via RXTX arrive all at once. >>> > >>> > Everything was fine in the spring, so what could have happened? Windows >>> > update? >>> > >>> > -Nate >>> > >>> > _______________________________________________ >>> > Rxtx mailing list >>> > Rxtx at qbang.org >>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>> > >>> > >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Wed Sep 9 03:54:45 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 12:54:45 +0300 Subject: [Rxtx] Xcode 3.x project available in CVS Message-ID: Hi everyone, I've just committed Apple Xcode 3.x (preferably 3.2) compatible project to CVS. The project can be used to develop and build Mac OS X 10.5+ compatible Universal Binary JNI library and RXTXcomm.jar. It's does not have dependencies to existing Autotools based build scripts - only standard Xcode installation is required. The older Xcode 2.x project is still there, but please note that it's not compatible with newer Xcode versions due to its dependency to deprecated Jam build system. The new project is available in rxtx-devel/MACOSX_IDE/Xcode3 How to get the source code from CVS: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Latest Xcode can be downloaded from Apple: http://developer.apple.com/technology/xcode.html -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 05:07:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 14:07:05 +0300 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: Nathaniel, I agree with Michael that your issue is probably with incorrect hardware flow control (RTS/CTS + possibly DTR/DSR). With RXTX you can do things manually, automatically or by mixing both ways. RXTX is "low-level" enough to let developer make those decisions. Which is proper. Automatic hardware flow-control: If you want to do automatic RTS/CTS flow control in both directions (from and to PC) you must set: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Note that you must combine flow control flags with bitwise OR ( ' | ' ) Manual: If you want to bypass all flow controls signals, or handle them manually you must set: setFlowControlMode( SerialPort.FLOWCONTROL_NONE ); In manual mode, you must manually handle controlling signals from PC and reading flow control signals from by the device: RTS - Request To Send -- setRTS() method can used to set this CTS - Clear To Send -- isCTS() method can be used to read this For example, it is entirely possible to manually implement normal RTS/ CTS flow control with RXTX without relying on low-level automatic implementation. Mixed: You can also configure serial port to handle RTS/CTS automatically in only one direction, then you must set one of: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN ); or setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_OUT ); Then you can either ignore or implement manually the flow control scheme in the other direction. DTR and DSR: These are not officially flow control signals, but might affect external devices (disable, standby etc.). Use and meaning of these depends on the device. DTR - Data Terminal Ready -- setDTR() method DSR - Data Set Ready -- setDSR() method CTS/RTS standards: Please note that there are two standard ways RTS/CTS flow control is done (depends on the device): asymmetric (RS-232) symmetric (RS-232-E / TIA-232-E) For more info see: http://en.wikipedia.org/wiki/RS232#RTS.2FCTS_handshaking Some devices may even use RTS/CTS to some other non-standard purpose. With those devices, enabling automatic RTS/CTS could cause very strange behaviour as they clearly require manual control of CTS/RTS. ---- As far as I know, RXTX properly controls all these signals all the way to actual RS232 pins - unless there is a new platform incompatibility bug that I'm not aware of;) Mostly it's just wrong combination and/or usage of these additional signals that cause problems receiving or sending. And the only solution is to really *know* how your device wants these signals handled - and then code your RXTX application accordingly. Creating non-standard cable is not the right solution in my opinion. Unfortunately some applications (like HyperTerminal for example) might hit more or less accidentally to the right combination of RTS/CTS/DTR/ DSR usage and make RXTX look bad in comparison. While all RXTX does by default is - well - nothing. It gives full control the developer. -- I > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port >> Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I >> found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't >> look wrong >> to me. Am I looking at the right function or is the problem >> somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > > >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store >>> tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since >>> the old >>> cables aren't around anymore. The hardware's manual says nothing >>> except to >>> use a "Straight cable" but I figured that if it worked in >>> HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that >>> communicates with >>> the device (but doesn't do what I want, which is why I'm rolling >>> my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's >>> RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but >>> only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> > >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect >>>> to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your >>>> device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>>> (Sorry if this is a double post, but I sent my original message >>>>> without >>>>> subscribing, and since this is an urgent problem, I thought I'd >>>>> resend >>>>> after >>>>> subscribing to bypass the moderator limbo zone) >>>>> >>>>> Hi all, >>>>> >>>>> I've asked my question on StackOverflow already, so rather than >>>>> copy-paste >>>>> the question here, I'd like to redirect you there. >>>>> >>>>> Short version, I am no longer able to receive anything over >>>>> RS-232 with >>>>> RXTX, but other programs work fine. I'm definitely sending things, >>>>> because >>>>> when I connect with a different program, all the responses to the >>>>> commands I >>>>> sent via RXTX arrive all at once. >>>>> >>>>> Everything was fine in the spring, so what could have happened? >>>>> Windows >>>>> update? >>>>> >>>>> -Nate >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 06:11:11 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 15:11:11 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings Message-ID: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Hi, Summary: Patch includes multiple minor code quality improvements and also fixes one possible null pointer segfault on Mac. After this patch, compilation on Mac OS X is error/warning free even with gcc -Wall setting. I'll submit more code quality patches later that focus more on linux/ win/java. Fixes: Code quality: - First level parentheses around assignment used as while-loop truth value - Some printf formats not a string literals and including no format arguments Invalid null pointer usage: - Mac: IOMasterPort was called with (int)NULL which does not always resolve to segfault safe value. Corrected to use MACH_PORT_NULL instead. Patch: The patch is against CVS head (@2009/09/09). Attached patch file is in 'cvs diff -up' format. I'll commit this patch to the CVS later this week if there are no objections. Feel free to comment. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090909.patch Type: application/octet-stream Size: 1966 bytes Desc: not available URL: From m.j.tandy at warwick.ac.uk Wed Sep 9 06:57:55 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 13:57:55 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> OK, I just ran a test with my copy of RxTx and the following program: import gnu.io.*; public class SerialTest { public static void main(String[] args) { try { CommPortIdentifier portid = CommPortIdentifier.getPortIdentifier("COM9"); SerialPort serialPort = (SerialPort)portid.open("Serial port DTR/RTS test", 1000); serialPort.setSerialPortParams(4800, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.disableReceiveTimeout(); for (int i=0 ; i<60 ; i++) { serialPort.setDTR(true); serialPort.setRTS(true); Thread.sleep(1000); serialPort.setDTR(false); serialPort.setRTS(false); Thread.sleep(1000); } } catch (Exception e) { e.printStackTrace(); System.exit(1); } System.exit(0); } } I'm using a USB-serial converter (Prolific PL-2303) and I used a multimeter to check that my DTR and RTS pins were both toggling, and they were - between +7 and -6.4 volts. In other words, on the computer I'm using at the moment, with the version of RxTx I'm using at the moment, setDTR and setRTS both seem to work fine. I don't know if it's worth it for you to perform the same test. I gather there are several different configurations for hardware flow control, (DTR/DSR handshaking as well as RTS/CTS handshaking, handshaking for half-duplex operation, and similar) so the cable that worked for me might still be worth a try. 2009/9/9 Michael Tandy : > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong >> to me. Am I looking at the right function or is the problem somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since the old >>> cables aren't around anymore. The hardware's manual says nothing except to >>> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that communicates with >>> the device (but doesn't do what I want, which is why I'm rolling my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>> > (Sorry if this is a double post, but I sent my original message without >>>> > subscribing, and since this is an urgent problem, I thought I'd resend >>>> > after >>>> > subscribing to bypass the moderator limbo zone) >>>> > >>>> > Hi all, >>>> > >>>> > I've asked my question on StackOverflow already, so rather than >>>> > copy-paste >>>> > the question here, I'd like to redirect you there. >>>> > >>>> > Short version, I am no longer able to receive anything over RS-232 with >>>> > RXTX, but other programs work fine. I'm definitely sending things, >>>> > because >>>> > when I connect with a different program, all the responses to the >>>> > commands I >>>> > sent via RXTX arrive all at once. >>>> > >>>> > Everything was fine in the spring, so what could have happened? Windows >>>> > update? >>>> > >>>> > -Nate >>>> > >>>> > _______________________________________________ >>>> > Rxtx mailing list >>>> > Rxtx at qbang.org >>>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>>> > >>>> > >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > From david at attglobal.net Wed Sep 9 09:17:27 2009 From: david at attglobal.net (David Schmidt) Date: Wed, 09 Sep 2009 11:17:27 -0400 Subject: [Rxtx] 2.2 Release plans Message-ID: <4AA7C707.5060802@attglobal.net> I'm holding off releasing an update to my project (adtpro.sourceforge.net) to support OSX Snow Leopard because I'd like to ship an "official" build of rxtx 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for toggling a port off). CVS is looking great on OSX - thanks to all who have been hard at work on that. I wish there were just one more update - Pre3? :-) My question... If I wanted to make a release in, say, a week... would it pay to wait for rxtx, or should I plan to build and ship a local build of 2.2 out of CVS myself? - David Schmidt From tjarvi at qbang.org Wed Sep 9 19:14:29 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:14:29 -0600 (MDT) Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: On Wed, 9 Sep 2009, Ilkka Myller wrote: > Hi, > > Summary: > > Patch includes multiple minor code quality improvements and also fixes one > possible null pointer segfault on Mac. > After this patch, compilation on Mac OS X is error/warning free even with gcc > -Wall setting. > I'll submit more code quality patches later that focus more on > linux/win/java. > > Fixes: > > Code quality: > - First level parentheses around assignment used as while-loop truth value > - Some printf formats not a string literals and including no format arguments > > Invalid null pointer usage: > - Mac: IOMasterPort was called with (int)NULL which does not always resolve > to segfault safe value. Corrected to use MACH_PORT_NULL instead. > > Patch: > > The patch is against CVS head (@2009/09/09). > Attached patch file is in 'cvs diff -up' format. > > I'll commit this patch to the CVS later this week if there are no objections. > Feel free to comment. > These ifdefs can go. If you like I can remove them when you are done. #ifdef DEBUG_MW mexErrMsgTxt( msg ); #else They are just printf like debug messages for use in an environment in which I could not get directly to stderr/stdout. I don't think anyone uses them anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Sep 9 19:17:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:17:43 -0600 (MDT) Subject: [Rxtx] 2.2 Release plans In-Reply-To: <4AA7C707.5060802@attglobal.net> References: <4AA7C707.5060802@attglobal.net> Message-ID: On Wed, 9 Sep 2009, David Schmidt wrote: > I'm holding off releasing an update to my project (adtpro.sourceforge.net) to > support OSX Snow Leopard because I'd like to ship an "official" build of rxtx > 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for > toggling a port off). CVS is looking great on OSX - thanks to all who have > been hard at work on that. I wish there were just one more update - Pre3? > :-) > > My question... If I wanted to make a release in, say, a week... would it pay > to wait for rxtx, or should I plan to build and ship a local build of 2.2 out > of CVS myself? > Hi David, I would suggest planning on shipping a local build in a 1 week timeframe. We could put another prerelease up but there are still fixes coming in. -- Trent Jarvi tjarvi at qbang.org From ilkka at myller.com Wed Sep 9 23:07:34 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:07:34 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: <04A41559-598C-4B6E-821A-DA90CB6228E7@myller.com> Patch (im-20090909.patch) has been committed to the CVS. Trent: I'll include DEBUG_MW cleanup to my next patch. > > On Wed, 9 Sep 2009, Ilkka Myller wrote: > >> Hi, >> >> Summary: >> >> Patch includes multiple minor code quality improvements and also >> fixes one possible null pointer segfault on Mac. >> After this patch, compilation on Mac OS X is error/warning free >> even with gcc -Wall setting. >> I'll submit more code quality patches later that focus more on >> linux/win/java. >> >> Fixes: >> >> Code quality: >> - First level parentheses around assignment used as while-loop >> truth value >> - Some printf formats not a string literals and including no format >> arguments >> >> Invalid null pointer usage: >> - Mac: IOMasterPort was called with (int)NULL which does not always >> resolve to segfault safe value. Corrected to use MACH_PORT_NULL >> instead. >> >> Patch: >> >> The patch is against CVS head (@2009/09/09). >> Attached patch file is in 'cvs diff -up' format. >> >> I'll commit this patch to the CVS later this week if there are no >> objections. >> Feel free to comment. >> > > These ifdefs can go. If you like I can remove them when you are done. > > #ifdef DEBUG_MW > mexErrMsgTxt( msg ); > #else > > They are just printf like debug messages for use in an environment > in which I could not get directly to stderr/stdout. I don't think > anyone uses them anymore. > > -- > Trent Jarvi > tjarvi at qbang.org From ilkka at myller.com Wed Sep 9 23:35:13 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:35:13 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= Message-ID: Hi, Summary: Patch fixes compiling on Linux distributions/kernels that dont ship with linux/utsrelease.h header and therefore have no UTS_RELEASE defined. Usually this applies only to newer distributions and/or kernels - for example Ubuntu 9.04. Fixes: The UTS_RELEASE vs uname checking in initialization functions is now done only in debug build and only when UTS_RELEASE is actually defined. Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910.patch Type: application/octet-stream Size: 9542 bytes Desc: not available URL: From ilkka at myller.com Thu Sep 10 06:43:02 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 15:43:02 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= In-Reply-To: References: Message-ID: Patch has been committed to CVS. > Hi, > > Summary: > > Patch fixes compiling on Linux distributions/kernels that dont ship > with linux/utsrelease.h header and therefore have no UTS_RELEASE > defined. > Usually this applies only to newer distributions and/or kernels - > for example Ubuntu 9.04. > > Fixes: > > The UTS_RELEASE vs uname checking in initialization functions is now > done only in debug build and only when UTS_RELEASE is actually > defined. > > Patch: > > The patch is against CVS head (@2009/09/10). > Attached patch file is in 'cvs diff -up' format. > > > Thanks, > > -- > I > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Thu Sep 10 09:08:01 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 18:08:01 +0300 Subject: [Rxtx] [Patch] Remove unused MathWorks MATLAB DEBUG_MW ifdefs Message-ID: <6DB57DB1-A47E-4435-9CD6-212B671A2849@myller.com> Summary: Patch removes unused MathWorks MATLAB timing debug ifdefs (DEBUG_MW). This is a request from Trent. Fixes: - Removes DEBUG_MW definitions - Removes unused mex....() function definitions - Corrects DEBUG_TIMING to work properly without mexPrintf (with Mac OS X specific format string fixes included) - Removes unused/duplicate timeval struct and DEBUG_TIMING definitions from SerialImp.c and SerialImp.h - Corrects fprintf call in SerialImp.cpp Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910b.patch Type: application/octet-stream Size: 9841 bytes Desc: not available URL: From Kapil_Gupta at hcl.in Thu Sep 10 10:25:29 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 10 Sep 2009 21:55:29 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, I am getting some problem with RXTX on macintosh (reading some data from the device attached to the usb port through usb to serial mechanism). I used the RXTX 2.1.7 then I got PortInUseException but after using 2.2pre it worked fine. But it works only for the first time, it hangs in the second time while opening the port. Please find the attached code. This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Thu Sep 10 13:00:14 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 22:00:14 +0300 Subject: [Rxtx] [Patch] Implement return value checking to file I/O calls Message-ID: Summary: The return value of some functions should always be used. For example, it is dangerous to not check the return value of a write(), read(), open(), fscanf() calls. This patch fixes such occurences in RXTX code. For example: unchecked read() call could result in later - and often seemingly unrelated - segfault due to undefined read buffer contents. After this patch the Linux build process is error/warning free even with gcc -Wall -Werror. Fixes: - Implemented return value checking to file I/O calls in SerialImp.c:fhs_lock(), uucp_lock() and is_device_locked() functions. - Added error recovery for fuserImp.c fscanf() calls. Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910c.patch Type: application/octet-stream Size: 3370 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Thu Sep 10 13:08:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 22:08:05 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> Hi Kapil, I believe this issue has been fixed in CVS version, but still exists in 2.2pre2 available from RXTX wiki. For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html As you've seen from the recent patches announced on this list, we are working very hard to make a new 2.2pre(?) release available. Meanwhile, you can compile your own RXTX binaries from CVS source. On Mac it should be exceptionally easy with new Xcode 3.x project files. Thank you for your patience, -- I > > I am getting some problem with RXTX on macintosh (reading some data > from the device attached to the usb port through usb to serial > mechanism). I used the RXTX 2.1.7 then I got PortInUseException but > after using 2.2pre it worked fine. But it works only for the first > time, it hangs in the second time while opening the port. From ilkka at myller.com Fri Sep 11 04:07:22 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 13:07:22 +0300 Subject: [Rxtx] [Patch] Windows build improvements (MinGW32, MSVC and LCC) Message-ID: <81D06766-8D51-485A-B2A2-624C8EA690BA@myller.com> Summary: Fixes various compiler warnings with Windows builds. Removes unused code blocks from compilation. After this patch the Windows build process is error/warning free with MinGW32, MSVC and LCC compilers - even with -Wall enabled. Does not fix: Latest LCC compiler version still fails even after this patch due to compiler trap error. Trap error does not specify source code location - it fails outputting SerialImp.obj binary. Compiling SerialImp.c without binary output works. Could this be a bug in LCC? Tested with clean RXTX source, latest standard LCC installation and with both Windows Vista SP1 x86 and Windows XP SP3 x86. Patch: The patch is against CVS (@2009/09/11). Attached patch file is in 'cvs diff -up' format. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090911.patch Type: application/octet-stream Size: 6673 bytes Desc: not available URL: From Kapil_Gupta at hcl.in Fri Sep 11 10:21:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Fri, 11 Sep 2009 19:51:24 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Ilkka, I tried getting the source code from the CVS but we could not able to do so, the CVS was not responding. Then we downloaded the 2.2 pre2 code and made the changes that are described in http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html but the problem didn't change. First time the device responds well and the second time it hangs. Did you see the code that we have sent to you, so that you can suggest if we are doing something wrong in our code. Again attaching if you have deleted that. Please suggest (does the CVS code can help rather using the patch provided by you?). Thanks, Kapil -----Original Message----- From: Ilkka Myller [mailto:ilkka at myller.com] Sent: Friday, September 11, 2009 12:38 AM To: Kapil Gupta Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Hi Kapil, I believe this issue has been fixed in CVS version, but still exists in 2.2pre2 available from RXTX wiki. For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html As you've seen from the recent patches announced on this list, we are working very hard to make a new 2.2pre(?) release available. Meanwhile, you can compile your own RXTX binaries from CVS source. On Mac it should be exceptionally easy with new Xcode 3.x project files. Thank you for your patience, -- I > > I am getting some problem with RXTX on macintosh (reading some data > from the device attached to the usb port through usb to serial > mechanism). I used the RXTX 2.1.7 then I got PortInUseException but > after using 2.2pre it worked fine. But it works only for the first > time, it hangs in the second time while opening the port. DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Fri Sep 11 11:33:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 18:33:33 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Hi Kapil, For CVS: Instructions at the old rxtx website are incorrect. Trent updated them, but to a wrong server address "qgang.org" -- the correct server is "qbang.org". Please follow instructions from rxtx wiki: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code About testing your code: When I have time (maybe this weekend), I'll test your code using Mac OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. What USB serial port you are using with your Mac? Something with FTDI chip? or maybe Prolific? What adapter driver version you are using? Just asking, so I can test with the same configuration. Meanwhile I suggest you: - Make sure you have the latest USB Serial adapter drivers, so we can eliminate past issues with those. - Check that you are not having multiple copies of librxtxSerial.jnilib (possibly different versions) in your java library path (=trouble;) - Check for any USB Serial adaptors kernel extension error messages in system log after testing your software (use Console.app to browse logs) -- I Kapil Gupta kirjoitti 11.9.2009 kello 17.21: > Hi Ilkka, > > I tried getting the source code from the CVS but we could not able > to do so, the CVS was not responding. Then we downloaded the 2.2 > pre2 code and made the changes that are described in http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html > but the problem didn't change. First time the device responds well > and the second time it hangs. > > Did you see the code that we have sent to you, so that you can > suggest if we are doing something wrong in our code. Again attaching > if you have deleted that. Please suggest (does the CVS code can help > rather using the patch provided by you?). > > Thanks, > Kapil > > -----Original Message----- > From: Ilkka Myller [mailto:ilkka at myller.com] > Sent: Friday, September 11, 2009 12:38 AM > To: Kapil Gupta > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second > time port open > > Hi Kapil, > > I believe this issue has been fixed in CVS version, but still exists > in 2.2pre2 available from RXTX wiki. > > For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html > > As you've seen from the recent patches announced on this list, we are > working very hard to make a new 2.2pre(?) release available. > > Meanwhile, you can compile your own RXTX binaries from CVS source. On > Mac it should be exceptionally easy with new Xcode 3.x project files. > > > Thank you for your patience, > > > -- > I > > >> >> I am getting some problem with RXTX on macintosh (reading some data >> from the device attached to the usb port through usb to serial >> mechanism). I used the RXTX 2.1.7 then I got PortInUseException but >> after using 2.2pre it worked fine. But it works only for the first >> time, it hangs in the second time while opening the port. > > > DISCLAIMER: > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential > and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of this > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > ----------------------------------------------------------------------------------------------------------------------- > From ilkka at myller.com Fri Sep 11 13:51:13 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 20:51:13 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Message-ID: <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> Ok, I debugged your code on Mac using USB-RS232 adapter + loopback adapter. My findings: there are no issues with RXTX in your code -- there are issues with threading and synchronization. Primary issue: you essentially lock the JVM main thread to 100% CPU usage with infinite loop: while (!processCompleted) { ; } Now.. I'm going to give you a bad advice, mostly because you have bigger threading issues there.. but we must continue somehow: A quick remedy to previous is: while (!processCompleted) { Thread.yield(); } Thread yielding gives other threads atleast a chance to run (and to processCompleted boolean to actually update in main thread context). What happens next is that your main-thread is allowed to continue and proceeds to closeConnection() call it otherwise would never reach. After that, connection closes properly.. main() method continues to "System.out.println(result);" and proceeds to exit JVM.. .. except.. Secondary issue: Exit is one thing JVM cant do since you have left a Timer thread hanging without proper closing in getData() method. Cancel it (uncomment that line) - and your code completes main() to a clean JVM exit. So, my advice to you is to focus on fixing threading, timers and synchronization. Design those well and everything works. Multithreading, done well or not, will not usually confuse RXTX ... but your own code might not be so lucky. -- I > > When I have time (maybe this weekend), I'll test your code using Mac > OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. >> >> Did you see the code that we have sent to you, so that you can >> suggest if we are doing something wrong in our code. Again >> attaching if you have deleted that. Please suggest (does the CVS >> code can help rather using the patch provided by you?). -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 11 17:19:26 2009 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 11 Sep 2009 17:19:26 -0400 Subject: [Rxtx] Can't run my Netbeans/Java s/w on a MAC Message-ID: <4AAABEDE.7020508@howardz.com> An HTML attachment was scrubbed... URL: From ilkka at myller.com Fri Sep 11 17:41:10 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 12 Sep 2009 00:41:10 +0300 Subject: [Rxtx] Can't run my Netbeans/Java s/w on a MAC In-Reply-To: <4AAABEDE.7020508@howardz.com> References: <4AAABEDE.7020508@howardz.com> Message-ID: <35D4BD73-B8CC-4DEE-A846-8858C9C9EBC7@myller.com> Hi, The bug that causes the segfault (invalid memory access) has been fixed (in CVS): http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html Next prerelease is coming (soon I hope), but the the 2.2pre2 fails when reopening the serial port on Mac OS X. -- I > > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] Jar > version = RXTX-2.2pre1 > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] native > lib Version = RXTX-2.2pre2 > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] Invalid > memory access of location 0x12b5e3938 rip=0x12955012f > 9/6/09 3:46:00 PM ReportCrash[6164] Saved crash report for java > [6162] version 13.0.0 (13.0.0) to /Users/myles/Library/Logs/ > DiagnosticReports/java_2009-09-06-154600_myles-PowerBook-PP-108.crash -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Fri Sep 11 22:15:31 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 11 Sep 2009 20:15:31 -0600 (MDT) Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Message-ID: On Fri, 11 Sep 2009, Ilkka Myller wrote: > Hi Kapil, > > For CVS: > > Instructions at the old rxtx website are incorrect. Trent updated them, but > to a wrong server address "qgang.org" -- the correct server is "qbang.org". > Please follow instructions from rxtx wiki: > > http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code The old website has been corrected. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 1 02:38:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 1 Sep 2009 02:38:40 -0600 (MDT) Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks Ilkka The problem should be resolved (confirmed from two locations). I'll be trying to hunt down a Snow Leopard box tomorrow evening as well. On Tue, 1 Sep 2009, Ilkka Myller wrote: > Hi, > > CVS server is reachable, but when trying anonymous login it replies: > > " > Fatal error, aborting. > anonymous: no such system user > " > > It seems that the anonymous cvs account is not yet properly configured on the > new system. > > -- > I > >> On Mon, 31 Aug 2009, Trent Jarvi wrote: >> >> The server has been beemed to another location for those experiencing >> routing problems. >> >> in bash: >> >> export CVSROOT=:pserver:anonymous at qbang.org:2401/var/cvs/cvsroot >> cvs login (no passwd) >> cvs co -r commapi-0-0-1 rxtx-devel >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Tue Sep 1 03:05:59 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 12:05:59 +0300 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks, The new CVS server works well :) I can also confirm that latest CVS version builds properly with unmodified Snow Leopard (Mac OS X 10.6) system: Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 gcc version 4.2.1 (Apple Inc. build 5646) Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) --> Resulting JNI library (Universal Binary): i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = 9d15fc488b301da8bf65b2c9456a7bbb --> Resulting JAR: RXTXComm.jar / 60942 bytes MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 Atleast it builds.. and probably works too. I have not tested that yet. -- I Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > The problem should be resolved (confirmed from two locations). I'll > be trying to hunt down a Snow Leopard box tomorrow evening as well. From jimmy.lee at emotum.com Tue Sep 1 05:07:19 2009 From: jimmy.lee at emotum.com (Jimmy Lee [emotum]) Date: Tue, 1 Sep 2009 21:07:19 +1000 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: <112685a90909010407i6054acb5tc2b12196797bfaf1@mail.gmail.com> Could we access to the binaries? Please :) 2009/9/1 Ilkka Myller > Thanks, > > The new CVS server works well :) > > I can also confirm that latest CVS version builds properly with unmodified > Snow Leopard (Mac OS X 10.6) system: > > Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_I386 i386 > gcc version 4.2.1 (Apple Inc. build 5646) > Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) > > > --> Resulting JNI library (Universal Binary): > > i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes > > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 > librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc > > MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = > 9d15fc488b301da8bf65b2c9456a7bbb > > > --> Resulting JAR: > > RXTXComm.jar / 60942 bytes > > MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 > > > > Atleast it builds.. and probably works too. I have not tested that yet. > > -- > I > > Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > > The problem should be resolved (confirmed from two locations). I'll be >> trying to hunt down a Snow Leopard box tomorrow evening as well. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Tue Sep 1 06:21:28 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Tue, 1 Sep 2009 08:21:28 -0400 (EDT) Subject: [Rxtx] Snow Leopard binaries Message-ID: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> +1 for binaries - pretty please with sugar on top... -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com From fredm at alum.mit.edu Tue Sep 1 06:24:17 2009 From: fredm at alum.mit.edu (Fred G. Martin) Date: Tue, 1 Sep 2009 08:24:17 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> Message-ID: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> You can find one here: http://iharder.sourceforge.net/current/java/ Also, you need to add yourself (any rxtx user) to the uucp group. Niutils don't exist, but dscl is a replacement. There is info for using it here: http://aplawrence.com/MacOSX/directory_services.html Fred On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Tue Sep 1 07:03:37 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Tue, 1 Sep 2009 18:33:37 +0530 Subject: [Rxtx] Help for RXTX on mac Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time I am able to read the device but on second time, it hangs on COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then it was showing the PortInUseException, I replaced the RXTX library to 2.2Pre1 so it is showing this problem. Is this is a problem with RXTX on Mac? Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: From ilkka at myller.com Tue Sep 1 07:57:06 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 16:57:06 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:02:31 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:02:31 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:43:49 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:43:49 +0300 Subject: [Rxtx] Help for RXTX on mac In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE@myller.com> Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Arseneau at Sun.COM Tue Sep 1 08:51:32 2009 From: Eric.Arseneau at Sun.COM (Eric Arseneau) Date: Tue, 01 Sep 2009 07:51:32 -0700 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24@sun.com> Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 09:24:30 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 18:24:30 +0300 Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D@myller.com> Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Thu Sep 3 02:50:16 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Thu, 3 Sep 2009 10:50:16 +0200 Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s From Kapil_Gupta at hcl.in Thu Sep 3 06:52:21 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:22:21 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From Kapil_Gupta at hcl.in Thu Sep 3 07:15:19 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:45:19 +0530 Subject: [Rxtx] Rxtx Digest, Vol 25, Issue 3 In-Reply-To: References: Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C50BB@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi myller, I have attached the code with the mail. Please help me if I am doing something wrong in it. Thanks & Regards, Kapil Gupta -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of rxtx-request at qbang.org Sent: Thursday, September 03, 2009 4:15 PM To: rxtx at qbang.org Subject: Rxtx Digest, Vol 25, Issue 3 Send Rxtx mailing list submissions to rxtx at qbang.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qbang.org/mailman/listinfo/rxtx or, via email, send a message with subject or body 'help' to rxtx-request at qbang.org You can reach the person managing the list at rxtx-owner at qbang.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Rxtx digest..." Today's Topics: 1. Re: Snow Leopard binaries (Ilkka Myller) 2. Re: Snow Leopard binaries (Ilkka Myller) 3. Re: Help for RXTX on mac (Ilkka Myller) 4. Re: Snow Leopard binaries (Eric Arseneau) 5. Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters (Ilkka Myller) 6. RXTX multiple crashes (Kjetil ?ster?s) 7. RXTX 2.2Pre + MacMini+ Deadlock while second time port open (Kapil Gupta) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Sep 2009 16:57:06 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 1 Sep 2009 17:02:31 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <55EC133D-DC83-45A3-849C-02714904D580 at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 1 Sep 2009 17:43:49 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Help for RXTX on mac Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Tue, 01 Sep 2009 07:51:32 -0700 From: Eric Arseneau Cc: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24 at sun.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 1 Sep 2009 18:24:30 +0300 From: Ilkka Myller To: rxtx Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Thu, 3 Sep 2009 10:50:16 +0200 From: Kjetil ?ster?s To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s ------------------------------ Message: 7 Date: Thu, 3 Sep 2009 18:22:21 +0530 From: Kapil Gupta To: "rxtx at qbang.org" Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059 at NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset="us-ascii" Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: ------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx End of Rxtx Digest, Vol 25, Issue 3 *********************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From ilkka at myller.com Thu Sep 3 11:17:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 3 Sep 2009 20:17:27 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <4520677F-E8F0-46F5-B4AD-3AD3A7C2AED3@myller.com> Hi Kapil, The code is incomplete and I did not find anything I could to test/ debug with this. I also tried to find the actual serial port opening, but found only a call to missing method which creates the SerialPort object (?): serialPort = getSerialPortConnection( COMPort, this.readEvent.getDeviceName(), SerialCommConfig.DEVICE1[SerialCommConfig.TIMEOUT], SerialCommConfig.DEVICE1[SerialCommConfig.BAUDRATE], SerialCommConfig.DEVICE1[SerialCommConfig.DATABITS], SerialCommConfig.DEVICE1[SerialCommConfig.STOPBITS], SerialCommConfig.DEVICE1[SerialCommConfig.PARITY] ); The class SerialCommConfig is missing too. If this is a part of the actual code you are using, please note that you are not actually closing the serial port. The call to close() method is commented out: try { // serialPort.close(); } catch (Exception ex) { ex.printStackTrace(); } Re-opening of the serial port wont work if you haven't properly closed it first. -- I > > I am using RXTX on Macintosh to communicate to my device. First time > the device responds well but on second time, it hangs on > COMPort.open (name, timeout). > > I have attached the source code in a file. Please help me. > > Thanks & Best Regards, > Kapil -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorton at intellimec.com Thu Sep 3 11:37:55 2009 From: dmorton at intellimec.com (Daniel Morton) Date: Thu, 3 Sep 2009 13:37:55 -0400 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. (I haven't tried previous version though). Daniel Morton Java/J2EE Developer Tel +1 519.745.8887 x4331 Email dmorton at intellimec.com www.intellimec.com | www.iLane.com | www.drivesync.com Intelligent Mechatronic Systems Inc. 435 King Street North Waterloo, ON N2J 2Z5 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s Sent: Thursday, September 03, 2009 4:50 AM To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. From alexanderkiel at gmx.net Fri Sep 4 02:29:15 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 10:29:15 +0200 Subject: [Rxtx] Official Javadoc Location Message-ID: <1252052955.4025.80.camel@T61-KIEL> Hi List, I wasn't able to find an official location of RXTX Javadoc accessible over HTTP. Maybe someone can link me to it. If there is no such location, I would like to see one. I like to link from my own Javadoc to such a location. Thanks Alexander - e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:19:25 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:19:25 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> Message-ID: <1252055965.4025.84.camel@T61-KIEL> Hi Michael, thanks for the pointer. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 09:48 +0100, Michael Tandy wrote: > RxTx javadoc: http://users.frii.com/jarvi/rxtx/doc/index.html > Javax interface RxTx duplicates javadoc: > http://java.sun.com/products/javacomm/reference/api/index.html > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:22:14 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:22:14 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> Message-ID: <1252056134.4025.87.camel@T61-KIEL> Hi Eike, thanks, but I need a direct package pointer so that Javadoc will link the gnu.io packages automatically to the right location. Michael has pointed me to http://users.frii.com/jarvi/rxtx/doc/index.html which has the gnu.io packages. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 11:04 +0200, Eike Hinderk J?rrens wrote: > Hi Alexander, > it seems to me that RXTX is implementing this API: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Kind regards, > Eike > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kjetilos at gmail.com Fri Sep 4 03:43:41 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 11:43:41 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> Message-ID: <7a803d460909040243ke4449ecucbe2cd8b15761746@mail.gmail.com> Hi Daniel, This is interesting, what type of application are you making? Is there a lot of signaling on different COM ports at the same time in your application? In our application we have 11 devices connected to different COM ports, 9 of these are in active use when the application is running. I'm wondering how to use the RXTX library version 2.1.7 in this scenario without causing it to crash. After adding more signaling on the COM ports in our application we have now experienced other crashes and it is natural to think that it has something to do with our way of using RXTX from several threads at the same time. So my question is are there any methods like read/write/flush/close that are not thread safe and should be handled with care? And similarly is the RXTXPort.SerialInputStream and RXTXPort.SerialOutputStream thread safe? 2009/9/3 Daniel Morton : > I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. ?(I haven't tried previous version though). > > Daniel Morton > Java/J2EE Developer > > Tel ? ?+1 519.745.8887 x4331 > Email ? ?dmorton at intellimec.com > > > www.intellimec.com ?| ?www.iLane.com ?| ?www.drivesync.com > > > > Intelligent Mechatronic Systems Inc. > 435 King Street North Waterloo, ON N2J 2Z5 > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s > Sent: Thursday, September 03, 2009 4:50 AM > To: rxtx at qbang.org > Subject: [Rxtx] RXTX multiple crashes > > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x7d0d] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0ce75800): ?JavaThread "Y Worker" daemon > [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 > > Registers: > EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 > ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 > EIP=0x10007d0d, EFLAGS=0x00010202 > > Top of Stack: (sp=0x0d7ff6d8) > 0x0d7ff6d8: ? 0d7ff700 00000000 00000000 00000000 > 0x0d7ff6e8: ? 02a2eae8 00000123 00002958 0d7ff718 > 0x0d7ff6f8: ? 7c830887 7c90d28a 7c8664b5 00000e2c > 0x0d7ff708: ? 00002958 00000000 00000000 7c90cffa > 0x0d7ff718: ? 7c809bdb 00002958 0d7ff758 00000e40 > 0x0d7ff728: ? 00002958 02bd0468 0ce75800 080e4ee0 > 0x0d7ff738: ? 00000000 00000000 00000000 00000000 > 0x0d7ff748: ? 00000000 00000000 00000014 7c90d09a > > Instructions: (pc=0x10007d0d) > 0x10007cfd: ? 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 > 0x10007d0d: ? 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 > > > Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x7d0d] > J ?gnu.io.RXTXPort.nativeDrain(Z)Z > J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > ... > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x9c55] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0cddf400): ?JavaThread "XXX Worker" daemon > [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 > > Registers: > EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 > ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 > EIP=0x10009c55, EFLAGS=0x00010206 > > Top of Stack: (sp=0x0bb8f830) > 0x0bb8f830: ? 00000000 00000000 c0000005 00000000 > 0x0bb8f840: ? 00000000 00f1f0a5 00000002 00000000 > 0x0bb8f850: ? 003a0100 0001003f 0bb8fb20 0b9ff918 > 0x0bb8f860: ? 00000000 00000000 0bb8fb68 0bb8fb20 > 0x0bb8f870: ? 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 > 0x0bb8f880: ? 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 > 0x0bb8f890: ? 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 > 0x0bb8f8a0: ? 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 > > Instructions: (pc=0x10009c55) > 0x10009c45: ? 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff > 0x10009c55: ? 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 > > > Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x9c55] > C ?[rxtxSerial.dll+0xa05e] > J ?gnu.io.RXTXPort.readByte()I > J ?gnu.io.RXTXPort$SerialInputStream.read()I > J ?java.io.FilterInputStream.read()I > ... > > -- > Kjetil ?ster?s > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kjetil ?ster?s From tjarvi at qbang.org Fri Sep 4 06:00:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Sep 2009 06:00:40 -0600 (MDT) Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x7d0d] > J gnu.io.RXTXPort.nativeDrain(Z)Z > J gnu.io.RXTXPort$SerialOutputStream.flush()V > Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x9c55] > C [rxtxSerial.dll+0xa05e] > J gnu.io.RXTXPort.readByte()I > J gnu.io.RXTXPort$SerialInputStream.read()I RXTX 2.1-7 has concurrency issues that will show upon multicore systems. These should be resolved in the 2.2 pre release. A user application could synchronize the read/write/open/close calls while using 2.1 to avoid the concurrency issue. The flush is probably following a write while the readByte is coming from read(byte b). The bugs existed in rxtx for a long time. I assume changes in the JVM and the presence of multicore systems exposed the issues. -- Trent Jarvi tjarvi at qbang.org From kjetilos at gmail.com Fri Sep 4 06:33:33 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 14:33:33 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <7a803d460909040533n1caf240y8168477a578bc45c@mail.gmail.com> Den 4. september 2009 14.00 skrev Trent Jarvi f?lgende: > > > On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > >> Hi >> >> We are using RXTX version 2.1.7 actively and lately we are having some >> issues with the RXTX library crashing. We are running a windows xp >> system with multiple COM ports where each COM port have a serial >> device connected. Lately we have increased the amount of signaling >> done over the COM ports and we are experiencing several odd crashes. I >> tried to search the mailinglist for something similar but was unable >> to find anything. At one time the RXTX crashed in the >> gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the >> gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack >> traces if someone is interested in having a look. Has anyone seen the >> same crashes? and does anyone know what can cause such crash? >> >> >> Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x7d0d] >> J ?gnu.io.RXTXPort.nativeDrain(Z)Z >> J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > >> Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x9c55] >> C ?[rxtxSerial.dll+0xa05e] >> J ?gnu.io.RXTXPort.readByte()I >> J ?gnu.io.RXTXPort$SerialInputStream.read()I > > > RXTX 2.1-7 has concurrency issues that will show upon multicore systems. > These should be resolved in the 2.2 pre release. ?A user application could > synchronize the read/write/open/close calls while using 2.1 to avoid the > concurrency issue. > > The flush is probably following a write while the readByte is coming from > read(byte b). > > The bugs existed in rxtx for a long time. ?I assume changes in the JVM and > the presence of multicore systems exposed the issues. > Ok, so we should look more into using a newer version of RXTX. The current version from the webpage is 2.2pre2, what is the stability status of this version. Is it good enough for use in a production environment? -- Kjetil ?ster?s From martinezrodolfo at gmail.com Fri Sep 4 13:39:57 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Fri, 4 Sep 2009 15:09:57 -0430 Subject: [Rxtx] Problem with data available event Message-ID: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Hello list members. I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a serial port USB adapter to communicate with an electronical inmunoassay analyzer. The program works porperly with one model of the analyzer series. It defines a protocol which every message sent should be replied with an ACK in order to continue with the communication. Now we are trying to communicate with another model of the same brand and series wich in theory should be much of the same of what was previously done. Unfortunately, that is not the case. The problem with this connection is that it never fires the Data Available serial port event. Is like if nothing was being received in the input stream. The following code always prints zero when the equipment should be transmitting. ----------------------- beginning of sample code ---------------------------------- SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", 10000); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); int len = 0; byte[] readBuffer = new byte[8]; while (true) { len = in.read(readBuffer); System.out.println(len); writer.writeACK(); // writing ACK to analyzer } ----------------------- end of sample code ------------------------------------------ We know that the analyzer is transmitting because HyperTerminal does shows the proper output. In fact, after running the above code and connecting via Hyperterminal all data is received in one block. Is like the data sent from the analyzer is being held somewhere in the way. Sniffing at the serial port, noticed that IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this helps to find what might be wrong or not, but here they are: On Hyperterminal: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 XonLimit:80 XoffLimit:200 On Java: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 XonLimit:0 XoffLimit:0 Thanks in advance for your help. Rodolfo M From ilkka at myller.com Sat Sep 5 04:36:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 5 Sep 2009 13:36:27 +0300 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <121198EE-65A4-463B-ACC7-29FFB9855B2C@myller.com> Hi Rodolfo, By default RXTX does not enable any flow control for the serial port. Please check what flow control you have active in HyperTerminal when you are able to receive data and then use the same flow control with RXTX serial port: serialPort.setFlowControlMode(int flowcontrol); Possible flowcontrol flags are (from SerialPort class) FLOWCONTROL_NONE FLOWCONTROL_RTSCTS_IN FLOWCONTROL_RTSCTS_OUT FLOWCONTROL_XONXOFF_IN FLOWCONTROL_XONXOFF_OUT For example, you can try enabling RTS/CTS hardware flow control. Note the bitwise OR operator ' | ': serialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Also if your device requires RTS/CTS flow control make sure you have fully connected serial cable (not just RX, TX, GND for example, but also RTS, CTS, DTR). One thing you might want to check is the state of DTR (Data Terminal Ready). Some devices wait for the DTR signal before they send any data. You can enable or disable DTR signal (high/low) with: serialPort.setDTR( boolean state ); -- I > Hello list members. > > I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a > serial port USB adapter to communicate with an electronical > inmunoassay analyzer. The program works porperly with one model of the > analyzer series. It defines a protocol which every message sent should > be replied with an ACK in order to continue with the communication. > Now we are trying to communicate with another model of the same brand > and series wich in theory should be much of the same of what was > previously done. Unfortunately, that is not the case. The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. > > ----------------------- beginning of sample code > ---------------------------------- > SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", > 10000); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > InputStream in = serialPort.getInputStream(); > OutputStream out = serialPort.getOutputStream(); > > int len = 0; > byte[] readBuffer = new byte[8]; > while (true) { > len = in.read(readBuffer); > System.out.println(len); > > writer.writeACK(); // writing ACK to analyzer > } > ----------------------- end of sample code > ------------------------------------------ > > We know that the analyzer is transmitting because HyperTerminal does > shows the proper output. In fact, after running the above code and > connecting via Hyperterminal all data is received in one block. Is > like the data sent from the analyzer is being held somewhere in the > way. Sniffing at the serial port, noticed that > IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this > helps to find what might be wrong or not, but here they are: > > On Hyperterminal: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 > XonLimit:80 XoffLimit:200 > > On Java: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 > XonLimit:0 XoffLimit:0 > > > Thanks in advance for your help. > Rodolfo M > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.weber99 at gmx.net Sun Sep 6 13:51:12 2009 From: karl.weber99 at gmx.net (Karl Weber) Date: Sun, 6 Sep 2009 21:51:12 +0200 Subject: [Rxtx] Cannot create lock file Message-ID: <200909062151.12228.karl.weber99@gmx.net> Hi, I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an opensuse repository as well as from the homepage of the rxtx project. I have already added the user to the group uucp, however, it does not have any effect. What else do I have to do to make it work? (It does work with user root, though.) The error message is: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL Thanks in advance, Karl From tjarvi at qbang.org Sun Sep 6 13:51:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 6 Sep 2009 13:51:42 -0600 (MDT) Subject: [Rxtx] Cannot create lock file In-Reply-To: <200909062151.12228.karl.weber99@gmx.net> References: <200909062151.12228.karl.weber99@gmx.net> Message-ID: On Sun, 6 Sep 2009, Karl Weber wrote: > Hi, > > I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an > opensuse repository as well as from the homepage of the rxtx project. > > I have already added the user to the group uucp, however, it does not have > any effect. What else do I have to do to make it work? (It does work with > user root, though.) > > The error message is: > > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to > create lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > > Thanks in advance, Karl Look at the group that owns /var/lock with ls -ld /var/lock The following should work as a user when they are in the correct group: touch /var/lock/test && rm -f /var/lock/test -- Trent Jarvi tjarvi at qbang.org From Luca.Catoni at sysdat.it Mon Sep 7 06:32:42 2009 From: Luca.Catoni at sysdat.it (Luca Catoni) Date: Mon, 7 Sep 2009 14:32:42 +0200 Subject: [Rxtx] time-out implementation Message-ID: I need to implement a simple timer class to manage time-out in my RS-232 serial communication with a remote device using the rxtx library. The functions that the timer should have are start(), and reset() and start() method must throw an exception (TimeoutException) when it expires. I am not an expert in concurrent programming and I do not have much knowledge on threads. myTimer.setExpirationTime(myvalue); ? public void serialEvent(SerialPortEvent event) { if (event.getEventType() == SerialPortEvent.OUTPUT_BUFFER_EMPTY) { // transmission ? out.write(?); try{ myTimer.start(); }catch(TimeoutException te){ myTimer.reset(); ? } ? if (event.getEventType() == SerialPortEvent.DATA_AVAILABLE) { // receiving in.read(?); if (mycondition){ myTimer.stop();//ok, timer NOT expired myTimer.reset();//now I can call start() method again in //transmission to restart my timer when I //have to transmit next data } Can anyone help me to implement the class MyTimer? thanks in advance. -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Mon Sep 7 06:49:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Mon, 7 Sep 2009 18:19:24 +0530 Subject: [Rxtx] 2.2Pre + MacMini+ Deadlock while second time port Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E22FB6F@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, Please find the updated code (close call was commented by mistake). This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From michael.erskine at ketech.com Mon Sep 7 09:13:03 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 7 Sep 2009 16:13:03 +0100 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Rodolfo Mart?nez > Subject: [Rxtx] Problem with data available event > The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. Hi Rodolfo, The sample code you provided doesn't implement or register any event listeners. Regards, Michael Erskine. From martinezrodolfo at gmail.com Mon Sep 7 10:21:22 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Mon, 7 Sep 2009 11:51:22 -0430 Subject: [Rxtx] Problem with data available event In-Reply-To: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> Message-ID: <30eacee0909070921l7f285765ue2c661963183fd2b@mail.gmail.com> On Mon, Sep 7, 2009 at 10:43 AM, Michael Erskine wrote: > Hi Rodolfo, > The sample code you provided doesn't implement or register any event listeners. > > Regards, > Michael Erskine. Hi Michael, I didn't write the event listeners declaration on the sample code for simplicity, but I do implement them on my real code. I should have mentioned it on the sample code anyway... my bad. I haven't had access to the device I'm trying to connect, but tomorrow will. And hope that with the explanation of Ilkka Myller will succeed this time. Thanks for your attention. Rodolfo M From ajmas at sympatico.ca Mon Sep 7 16:58:13 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 7 Sep 2009 18:58:13 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" I noticed in the page you posted posted you indicated that you patched two files. Did you submit the changes to Jarvi, so they could be included in the main code branch? Andr? From tjarvi at qbang.org Mon Sep 7 16:57:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Sep 2009 16:57:53 -0600 (MDT) Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On Mon, 7 Sep 2009, Andre-John Mas wrote: > > On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > >> Sorry, my rudeness was not intentional (a typo). >> Lets try again.. ;) >> >> "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > I noticed in the page you posted posted you indicated that you patched two > files. Did you submit the changes to Jarvi, so they could be included in the > main code branch? > Hi Andr? Ilkka is working with us to get changes in. I'm not sure about those two patches which may already be in CVS. I'll let him answer that. I've given him write access to CVS and asked him to cc the list non whitespace changes when they are ready. Right now he is asking questions off the list regarding cleaning up the Mac and w32 build files. -- Trent Jarvi tjarvi at qbang.org From nsp25 at cornell.edu Mon Sep 7 21:17:45 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Mon, 7 Sep 2009 23:17:45 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: (Sorry if this is a double post, but I sent my original message without subscribing, and since this is an urgent problem, I thought I'd resend after subscribing to bypass the moderator limbo zone) Hi all, I've asked my question on StackOverflow already, so rather than copy-paste the question here, I'd like to redirect you there . Short version, I am no longer able to receive anything over RS-232 with RXTX, but other programs work fine. I'm definitely sending things, because when I connect with a different program, all the responses to the commands I sent via RXTX arrive all at once. Everything was fine in the spring, so what could have happened? Windows update? -Nate -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.j.tandy at warwick.ac.uk Tue Sep 8 01:30:48 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Tue, 8 Sep 2009 08:30:48 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> OK, so: 1. It worked in spring but has stopped doing so and 2. The data all arrives at once when you start hyperterminal. Is it possible you're using a different serial cable to connect to the device, compared to the one you were using in spring? If so, the issue might be hardware flow control - that is, your device might be buffering data because it can't transmit it until your computer sets 'DTR' or 'RTS' or something like that. One way of bypassing hardware flow control is by using cables which cross over certain wires so that the right signals are always being sent; it's possible your old cable had these connections but your current cable doesn't have them. If you can find the old cable, you could put it back in and see if that fixes things? 2009/9/8 Nathaniel S. Parsons : > (Sorry if this is a double post, but I sent my original message without > subscribing, and since this is an urgent problem, I thought I'd resend after > subscribing to bypass the moderator limbo zone) > > Hi all, > > I've asked my question on StackOverflow already, so rather than copy-paste > the question here, I'd like to redirect you there. > > Short version, I am no longer able to receive anything over RS-232 with > RXTX, but other programs work fine. I'm definitely sending things, because > when I connect with a different program, all the responses to the commands I > sent via RXTX arrive all at once. > > Everything was fine in the spring, so what could have happened? Windows > update? > > -Nate > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Tue Sep 8 01:50:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 8 Sep 2009 10:50:33 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <111FEC9A-26BA-435C-BABC-314C7E4F23E5@myller.com> Hi all, Patches applied to the 2.1.7 binaries distributed by Robert Harder (http://iharder.sourceforge.net/current/java/ ) are already in the 2.2. Actually in 2.2 the issue with integer types handling seems to be fixed even more extensively than that single patch to 2.1.7 originally did. And yes, Trent has granted me CVS commit access. Thank you. First thing I'm going to focus on is the code quality and clean up: unused variables, invalid pointer usage etc.. Most of this just causing compile warnings - some harmless and some have potential for causing runtime problems. Instead of just blindly committing new changes to CVS, I've been discussing with Trent about the way things have been done in the RXTX CVS before. (how to handle white space patches, what needs to be discussed with the list first, proper locations for new files/ directories/subprojects, "the way things are done in RXTX"). But patches are coming and bugs will be fixed. I hope everyone will continue to submit the bugs they discover to this mailing list. Most important thing is to provide enough info (code;) so that the issue can be duplicated and eventually fixed. -- I > > > On Mon, 7 Sep 2009, Andre-John Mas wrote: >> >> I noticed in the page you posted posted you indicated that you >> patched two files. Did you submit the changes to Jarvi, so they >> could be included in the main code branch? >> > > Ilkka is working with us to get changes in. I'm not sure about > those two patches which may already be in CVS. I'll let him answer > that. > > I've given him write access to CVS and asked him to cc the list non > whitespace changes when they are ready. Right now he is asking > questions off the list regarding cleaning up the Mac and w32 build > files. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 15:35:19 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 17:35:19 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: Thanks for the response. I'll try to get to the electronics store tomorrow to get more serial cables, even if it isn't the problem. I am using a different serial cable than I was in the spring. It's actually a Male/Female cable with a female-female adapter since the old cables aren't around anymore. The hardware's manual says nothing except to use a "Straight cable" but I figured that if it worked in HyperTerminal, it should work in RXTX, right? Anyways, I've also noticed some things that are different between HyperTerminal, RXTX, and a separate program I found that communicates with the device (but doesn't do what I want, which is why I'm rolling my own program) HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and DTR indicators are green Other program - not sure what settings it thinks it's using, but only SPM's RTS indicator is green RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators are on. >From Serial Port Monitor's help files (paraphrased): the indicators display the state of the serial control lines RTS - Request To Send CTS - Clear To Send DTR - Data Terminal Ready Could this be related to the problem? -Nate On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > OK, so: > > 1. It worked in spring but has stopped doing so and > 2. The data all arrives at once when you start hyperterminal. > > Is it possible you're using a different serial cable to connect to the > device, compared to the one you were using in spring? > > If so, the issue might be hardware flow control - that is, your device > might be buffering data because it can't transmit it until your > computer sets 'DTR' or 'RTS' or something like that. > > One way of bypassing hardware flow control is by using cables which > cross over certain wires so that the right signals are always being > sent; it's possible your old cable had these connections but your > current cable doesn't have them. If you can find the old cable, you > could put it back in and see if that fixes things? > > > 2009/9/8 Nathaniel S. Parsons : > > (Sorry if this is a double post, but I sent my original message without > > subscribing, and since this is an urgent problem, I thought I'd resend > after > > subscribing to bypass the moderator limbo zone) > > > > Hi all, > > > > I've asked my question on StackOverflow already, so rather than > copy-paste > > the question here, I'd like to redirect you there. > > > > Short version, I am no longer able to receive anything over RS-232 with > > RXTX, but other programs work fine. I'm definitely sending things, > because > > when I connect with a different program, all the responses to the > commands I > > sent via RXTX arrive all at once. > > > > Everything was fine in the spring, so what could have happened? Windows > > update? > > > > -Nate > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 18:57:58 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 20:57:58 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: I added a call to setRTS() but nothing changed in Serial Port Monitor, no matter what the argument was. Is this a bug, or did I call the wrong function? I tried to find the c code behind this function, and I think I found it in rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong to me. Am I looking at the right function or is the problem somewhere else? -Nate On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons wrote: > Thanks for the response. I'll try to get to the electronics store tomorrow > to get more serial cables, even if it isn't the problem. > > I am using a different serial cable than I was in the spring. It's actually > a Male/Female cable with a female-female adapter since the old cables aren't > around anymore. The hardware's manual says nothing except to use a "Straight > cable" but I figured that if it worked in HyperTerminal, it should work in > RXTX, right? > > Anyways, I've also noticed some things that are different between > HyperTerminal, RXTX, and a separate program I found that communicates with > the device (but doesn't do what I want, which is why I'm rolling my own > program) > > HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and > DTR indicators are green > Other program - not sure what settings it thinks it's using, but only SPM's > RTS indicator is green > RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators > are on. > > From Serial Port Monitor's help files (paraphrased): the indicators display > the state of the serial control lines > > RTS - Request To Send > CTS - Clear To Send > DTR - Data Terminal Ready > > Could this be related to the problem? > > -Nate > > > On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > >> OK, so: >> >> 1. It worked in spring but has stopped doing so and >> 2. The data all arrives at once when you start hyperterminal. >> >> Is it possible you're using a different serial cable to connect to the >> device, compared to the one you were using in spring? >> >> If so, the issue might be hardware flow control - that is, your device >> might be buffering data because it can't transmit it until your >> computer sets 'DTR' or 'RTS' or something like that. >> >> One way of bypassing hardware flow control is by using cables which >> cross over certain wires so that the right signals are always being >> sent; it's possible your old cable had these connections but your >> current cable doesn't have them. If you can find the old cable, you >> could put it back in and see if that fixes things? >> >> >> 2009/9/8 Nathaniel S. Parsons : >> > (Sorry if this is a double post, but I sent my original message without >> > subscribing, and since this is an urgent problem, I thought I'd resend >> after >> > subscribing to bypass the moderator limbo zone) >> > >> > Hi all, >> > >> > I've asked my question on StackOverflow already, so rather than >> copy-paste >> > the question here, I'd like to redirect you there. >> > >> > Short version, I am no longer able to receive anything over RS-232 with >> > RXTX, but other programs work fine. I'm definitely sending things, >> because >> > when I connect with a different program, all the responses to the >> commands I >> > sent via RXTX arrive all at once. >> > >> > Everything was fine in the spring, so what could have happened? Windows >> > update? >> > >> > -Nate >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Tue Sep 8 21:54:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 21:54:26 -0600 (MDT) Subject: [Rxtx] rxtx is moving to the clouds Message-ID: rxtx is moving onto a cloud server. You may notice short outages as things move around. So far the following is done. http://rxtx.qbang.org (will redirect rxtx.org there for 2.2) http://bugzilla.qbang.org (bugs) The mail-list is tomorrow night. CVS and FTP will be last. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 8 22:03:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 22:03:26 -0600 (MDT) Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: On Tue, 8 Sep 2009, Nathaniel S. Parsons wrote: > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? Hi Nathaniel, That depends upon what you are running. WinCE is for embedded windows. The Windows source is in src/termios.c (called from src/SerialImp.c). -- Trent Jarvi tjarvi at qbang.org From m.j.tandy at warwick.ac.uk Wed Sep 9 03:27:10 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 10:27:10 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> I had a similar problem a while ago - hardware that would work with Hyperterminal but not with Rxtx. I don't know if this is a bug in RxTx or not - I tried to find where in the RxTx source code those functions are actually implemented - I got as far as the ioctl function in termios.c, where the TIOCMSET case sets the MSR byte in the termios struct, but I can't figure out where that gets written to the dcb struct's fDtrControl dword. It could be a bug, or it could just be me missing something. In any case, at the time I had this problem I wasn't equipped to debug RxTx so instead I created a special cable to satisfy the hardware's flow control while leaving the data connection straight through. Here's how I connected it: At the female end of the cable (i.e. the hardware I was connecting to) I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. I connected the ground and data pins straight through - that is, pin 5 female end to pin 5 male end, pin 2 female end to pin 2 male end, pin 3 female end to pin 3 male end. Anyway, using that cable bypassed the hardware's flow control, and got RxTx working just as well as HyperTerminal - although I slowed down my communication to make sure I didn't encounter a situation where the flow control would have come into effect, as I had bypassed it! Hope that helps. 2009/9/9 Nathaniel S. Parsons : > I added a call to setRTS() but nothing changed in Serial Port Monitor, no > matter what the argument was. Is this a bug, or did I call the wrong > function? > > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? > > -Nate > > On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > wrote: >> >> Thanks for the response. I'll try to get to the electronics store tomorrow >> to get more serial cables, even if it isn't the problem. >> >> I am using a different serial cable than I was in the spring. It's >> actually a Male/Female cable with a female-female adapter since the old >> cables aren't around anymore. The hardware's manual says nothing except to >> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >> should work in RXTX, right? >> >> Anyways, I've also noticed some things that are different between >> HyperTerminal, RXTX, and a separate program I found that communicates with >> the device (but doesn't do what I want, which is why I'm rolling my own >> program) >> >> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >> DTR indicators are green >> Other program - not sure what settings it thinks it's using, but only >> SPM's RTS indicator is green >> RXTX - no matter what flow control I set, only SPM's CTS and DTR >> indicators are on. >> >> From Serial Port Monitor's help files (paraphrased): the indicators >> display the state of the serial control lines >> >> RTS - Request To Send >> CTS - Clear To Send >> DTR - Data Terminal Ready >> >> Could this be related to the problem? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> wrote: >>> >>> OK, so: >>> >>> 1. It worked in spring but has stopped doing so and >>> 2. The data all arrives at once when you start hyperterminal. >>> >>> Is it possible you're using a different serial cable to connect to the >>> device, compared to the one you were using in spring? >>> >>> If so, the issue might be hardware flow control - that is, your device >>> might be buffering data because it can't transmit it until your >>> computer sets 'DTR' or 'RTS' or something like that. >>> >>> One way of bypassing hardware flow control is by using cables which >>> cross over certain wires so that the right signals are always being >>> sent; it's possible your old cable had these connections but your >>> current cable doesn't have them. If you can find the old cable, you >>> could put it back in and see if that fixes things? >>> >>> >>> 2009/9/8 Nathaniel S. Parsons : >>> > (Sorry if this is a double post, but I sent my original message without >>> > subscribing, and since this is an urgent problem, I thought I'd resend >>> > after >>> > subscribing to bypass the moderator limbo zone) >>> > >>> > Hi all, >>> > >>> > I've asked my question on StackOverflow already, so rather than >>> > copy-paste >>> > the question here, I'd like to redirect you there. >>> > >>> > Short version, I am no longer able to receive anything over RS-232 with >>> > RXTX, but other programs work fine. I'm definitely sending things, >>> > because >>> > when I connect with a different program, all the responses to the >>> > commands I >>> > sent via RXTX arrive all at once. >>> > >>> > Everything was fine in the spring, so what could have happened? Windows >>> > update? >>> > >>> > -Nate >>> > >>> > _______________________________________________ >>> > Rxtx mailing list >>> > Rxtx at qbang.org >>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>> > >>> > >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Wed Sep 9 03:54:45 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 12:54:45 +0300 Subject: [Rxtx] Xcode 3.x project available in CVS Message-ID: Hi everyone, I've just committed Apple Xcode 3.x (preferably 3.2) compatible project to CVS. The project can be used to develop and build Mac OS X 10.5+ compatible Universal Binary JNI library and RXTXcomm.jar. It's does not have dependencies to existing Autotools based build scripts - only standard Xcode installation is required. The older Xcode 2.x project is still there, but please note that it's not compatible with newer Xcode versions due to its dependency to deprecated Jam build system. The new project is available in rxtx-devel/MACOSX_IDE/Xcode3 How to get the source code from CVS: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Latest Xcode can be downloaded from Apple: http://developer.apple.com/technology/xcode.html -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 05:07:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 14:07:05 +0300 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: Nathaniel, I agree with Michael that your issue is probably with incorrect hardware flow control (RTS/CTS + possibly DTR/DSR). With RXTX you can do things manually, automatically or by mixing both ways. RXTX is "low-level" enough to let developer make those decisions. Which is proper. Automatic hardware flow-control: If you want to do automatic RTS/CTS flow control in both directions (from and to PC) you must set: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Note that you must combine flow control flags with bitwise OR ( ' | ' ) Manual: If you want to bypass all flow controls signals, or handle them manually you must set: setFlowControlMode( SerialPort.FLOWCONTROL_NONE ); In manual mode, you must manually handle controlling signals from PC and reading flow control signals from by the device: RTS - Request To Send -- setRTS() method can used to set this CTS - Clear To Send -- isCTS() method can be used to read this For example, it is entirely possible to manually implement normal RTS/ CTS flow control with RXTX without relying on low-level automatic implementation. Mixed: You can also configure serial port to handle RTS/CTS automatically in only one direction, then you must set one of: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN ); or setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_OUT ); Then you can either ignore or implement manually the flow control scheme in the other direction. DTR and DSR: These are not officially flow control signals, but might affect external devices (disable, standby etc.). Use and meaning of these depends on the device. DTR - Data Terminal Ready -- setDTR() method DSR - Data Set Ready -- setDSR() method CTS/RTS standards: Please note that there are two standard ways RTS/CTS flow control is done (depends on the device): asymmetric (RS-232) symmetric (RS-232-E / TIA-232-E) For more info see: http://en.wikipedia.org/wiki/RS232#RTS.2FCTS_handshaking Some devices may even use RTS/CTS to some other non-standard purpose. With those devices, enabling automatic RTS/CTS could cause very strange behaviour as they clearly require manual control of CTS/RTS. ---- As far as I know, RXTX properly controls all these signals all the way to actual RS232 pins - unless there is a new platform incompatibility bug that I'm not aware of;) Mostly it's just wrong combination and/or usage of these additional signals that cause problems receiving or sending. And the only solution is to really *know* how your device wants these signals handled - and then code your RXTX application accordingly. Creating non-standard cable is not the right solution in my opinion. Unfortunately some applications (like HyperTerminal for example) might hit more or less accidentally to the right combination of RTS/CTS/DTR/ DSR usage and make RXTX look bad in comparison. While all RXTX does by default is - well - nothing. It gives full control the developer. -- I > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port >> Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I >> found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't >> look wrong >> to me. Am I looking at the right function or is the problem >> somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > > >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store >>> tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since >>> the old >>> cables aren't around anymore. The hardware's manual says nothing >>> except to >>> use a "Straight cable" but I figured that if it worked in >>> HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that >>> communicates with >>> the device (but doesn't do what I want, which is why I'm rolling >>> my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's >>> RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but >>> only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> > >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect >>>> to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your >>>> device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>>> (Sorry if this is a double post, but I sent my original message >>>>> without >>>>> subscribing, and since this is an urgent problem, I thought I'd >>>>> resend >>>>> after >>>>> subscribing to bypass the moderator limbo zone) >>>>> >>>>> Hi all, >>>>> >>>>> I've asked my question on StackOverflow already, so rather than >>>>> copy-paste >>>>> the question here, I'd like to redirect you there. >>>>> >>>>> Short version, I am no longer able to receive anything over >>>>> RS-232 with >>>>> RXTX, but other programs work fine. I'm definitely sending things, >>>>> because >>>>> when I connect with a different program, all the responses to the >>>>> commands I >>>>> sent via RXTX arrive all at once. >>>>> >>>>> Everything was fine in the spring, so what could have happened? >>>>> Windows >>>>> update? >>>>> >>>>> -Nate >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 06:11:11 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 15:11:11 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings Message-ID: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Hi, Summary: Patch includes multiple minor code quality improvements and also fixes one possible null pointer segfault on Mac. After this patch, compilation on Mac OS X is error/warning free even with gcc -Wall setting. I'll submit more code quality patches later that focus more on linux/ win/java. Fixes: Code quality: - First level parentheses around assignment used as while-loop truth value - Some printf formats not a string literals and including no format arguments Invalid null pointer usage: - Mac: IOMasterPort was called with (int)NULL which does not always resolve to segfault safe value. Corrected to use MACH_PORT_NULL instead. Patch: The patch is against CVS head (@2009/09/09). Attached patch file is in 'cvs diff -up' format. I'll commit this patch to the CVS later this week if there are no objections. Feel free to comment. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090909.patch Type: application/octet-stream Size: 1966 bytes Desc: not available URL: From m.j.tandy at warwick.ac.uk Wed Sep 9 06:57:55 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 13:57:55 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> OK, I just ran a test with my copy of RxTx and the following program: import gnu.io.*; public class SerialTest { public static void main(String[] args) { try { CommPortIdentifier portid = CommPortIdentifier.getPortIdentifier("COM9"); SerialPort serialPort = (SerialPort)portid.open("Serial port DTR/RTS test", 1000); serialPort.setSerialPortParams(4800, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.disableReceiveTimeout(); for (int i=0 ; i<60 ; i++) { serialPort.setDTR(true); serialPort.setRTS(true); Thread.sleep(1000); serialPort.setDTR(false); serialPort.setRTS(false); Thread.sleep(1000); } } catch (Exception e) { e.printStackTrace(); System.exit(1); } System.exit(0); } } I'm using a USB-serial converter (Prolific PL-2303) and I used a multimeter to check that my DTR and RTS pins were both toggling, and they were - between +7 and -6.4 volts. In other words, on the computer I'm using at the moment, with the version of RxTx I'm using at the moment, setDTR and setRTS both seem to work fine. I don't know if it's worth it for you to perform the same test. I gather there are several different configurations for hardware flow control, (DTR/DSR handshaking as well as RTS/CTS handshaking, handshaking for half-duplex operation, and similar) so the cable that worked for me might still be worth a try. 2009/9/9 Michael Tandy : > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong >> to me. Am I looking at the right function or is the problem somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since the old >>> cables aren't around anymore. The hardware's manual says nothing except to >>> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that communicates with >>> the device (but doesn't do what I want, which is why I'm rolling my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>> > (Sorry if this is a double post, but I sent my original message without >>>> > subscribing, and since this is an urgent problem, I thought I'd resend >>>> > after >>>> > subscribing to bypass the moderator limbo zone) >>>> > >>>> > Hi all, >>>> > >>>> > I've asked my question on StackOverflow already, so rather than >>>> > copy-paste >>>> > the question here, I'd like to redirect you there. >>>> > >>>> > Short version, I am no longer able to receive anything over RS-232 with >>>> > RXTX, but other programs work fine. I'm definitely sending things, >>>> > because >>>> > when I connect with a different program, all the responses to the >>>> > commands I >>>> > sent via RXTX arrive all at once. >>>> > >>>> > Everything was fine in the spring, so what could have happened? Windows >>>> > update? >>>> > >>>> > -Nate >>>> > >>>> > _______________________________________________ >>>> > Rxtx mailing list >>>> > Rxtx at qbang.org >>>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>>> > >>>> > >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > From david at attglobal.net Wed Sep 9 09:17:27 2009 From: david at attglobal.net (David Schmidt) Date: Wed, 09 Sep 2009 11:17:27 -0400 Subject: [Rxtx] 2.2 Release plans Message-ID: <4AA7C707.5060802@attglobal.net> I'm holding off releasing an update to my project (adtpro.sourceforge.net) to support OSX Snow Leopard because I'd like to ship an "official" build of rxtx 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for toggling a port off). CVS is looking great on OSX - thanks to all who have been hard at work on that. I wish there were just one more update - Pre3? :-) My question... If I wanted to make a release in, say, a week... would it pay to wait for rxtx, or should I plan to build and ship a local build of 2.2 out of CVS myself? - David Schmidt From tjarvi at qbang.org Wed Sep 9 19:14:29 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:14:29 -0600 (MDT) Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: On Wed, 9 Sep 2009, Ilkka Myller wrote: > Hi, > > Summary: > > Patch includes multiple minor code quality improvements and also fixes one > possible null pointer segfault on Mac. > After this patch, compilation on Mac OS X is error/warning free even with gcc > -Wall setting. > I'll submit more code quality patches later that focus more on > linux/win/java. > > Fixes: > > Code quality: > - First level parentheses around assignment used as while-loop truth value > - Some printf formats not a string literals and including no format arguments > > Invalid null pointer usage: > - Mac: IOMasterPort was called with (int)NULL which does not always resolve > to segfault safe value. Corrected to use MACH_PORT_NULL instead. > > Patch: > > The patch is against CVS head (@2009/09/09). > Attached patch file is in 'cvs diff -up' format. > > I'll commit this patch to the CVS later this week if there are no objections. > Feel free to comment. > These ifdefs can go. If you like I can remove them when you are done. #ifdef DEBUG_MW mexErrMsgTxt( msg ); #else They are just printf like debug messages for use in an environment in which I could not get directly to stderr/stdout. I don't think anyone uses them anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Sep 9 19:17:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:17:43 -0600 (MDT) Subject: [Rxtx] 2.2 Release plans In-Reply-To: <4AA7C707.5060802@attglobal.net> References: <4AA7C707.5060802@attglobal.net> Message-ID: On Wed, 9 Sep 2009, David Schmidt wrote: > I'm holding off releasing an update to my project (adtpro.sourceforge.net) to > support OSX Snow Leopard because I'd like to ship an "official" build of rxtx > 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for > toggling a port off). CVS is looking great on OSX - thanks to all who have > been hard at work on that. I wish there were just one more update - Pre3? > :-) > > My question... If I wanted to make a release in, say, a week... would it pay > to wait for rxtx, or should I plan to build and ship a local build of 2.2 out > of CVS myself? > Hi David, I would suggest planning on shipping a local build in a 1 week timeframe. We could put another prerelease up but there are still fixes coming in. -- Trent Jarvi tjarvi at qbang.org From ilkka at myller.com Wed Sep 9 23:07:34 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:07:34 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: <04A41559-598C-4B6E-821A-DA90CB6228E7@myller.com> Patch (im-20090909.patch) has been committed to the CVS. Trent: I'll include DEBUG_MW cleanup to my next patch. > > On Wed, 9 Sep 2009, Ilkka Myller wrote: > >> Hi, >> >> Summary: >> >> Patch includes multiple minor code quality improvements and also >> fixes one possible null pointer segfault on Mac. >> After this patch, compilation on Mac OS X is error/warning free >> even with gcc -Wall setting. >> I'll submit more code quality patches later that focus more on >> linux/win/java. >> >> Fixes: >> >> Code quality: >> - First level parentheses around assignment used as while-loop >> truth value >> - Some printf formats not a string literals and including no format >> arguments >> >> Invalid null pointer usage: >> - Mac: IOMasterPort was called with (int)NULL which does not always >> resolve to segfault safe value. Corrected to use MACH_PORT_NULL >> instead. >> >> Patch: >> >> The patch is against CVS head (@2009/09/09). >> Attached patch file is in 'cvs diff -up' format. >> >> I'll commit this patch to the CVS later this week if there are no >> objections. >> Feel free to comment. >> > > These ifdefs can go. If you like I can remove them when you are done. > > #ifdef DEBUG_MW > mexErrMsgTxt( msg ); > #else > > They are just printf like debug messages for use in an environment > in which I could not get directly to stderr/stdout. I don't think > anyone uses them anymore. > > -- > Trent Jarvi > tjarvi at qbang.org From ilkka at myller.com Wed Sep 9 23:35:13 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:35:13 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= Message-ID: Hi, Summary: Patch fixes compiling on Linux distributions/kernels that dont ship with linux/utsrelease.h header and therefore have no UTS_RELEASE defined. Usually this applies only to newer distributions and/or kernels - for example Ubuntu 9.04. Fixes: The UTS_RELEASE vs uname checking in initialization functions is now done only in debug build and only when UTS_RELEASE is actually defined. Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910.patch Type: application/octet-stream Size: 9542 bytes Desc: not available URL: From ilkka at myller.com Thu Sep 10 06:43:02 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 15:43:02 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= In-Reply-To: References: Message-ID: Patch has been committed to CVS. > Hi, > > Summary: > > Patch fixes compiling on Linux distributions/kernels that dont ship > with linux/utsrelease.h header and therefore have no UTS_RELEASE > defined. > Usually this applies only to newer distributions and/or kernels - > for example Ubuntu 9.04. > > Fixes: > > The UTS_RELEASE vs uname checking in initialization functions is now > done only in debug build and only when UTS_RELEASE is actually > defined. > > Patch: > > The patch is against CVS head (@2009/09/10). > Attached patch file is in 'cvs diff -up' format. > > > Thanks, > > -- > I > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Thu Sep 10 09:08:01 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 18:08:01 +0300 Subject: [Rxtx] [Patch] Remove unused MathWorks MATLAB DEBUG_MW ifdefs Message-ID: <6DB57DB1-A47E-4435-9CD6-212B671A2849@myller.com> Summary: Patch removes unused MathWorks MATLAB timing debug ifdefs (DEBUG_MW). This is a request from Trent. Fixes: - Removes DEBUG_MW definitions - Removes unused mex....() function definitions - Corrects DEBUG_TIMING to work properly without mexPrintf (with Mac OS X specific format string fixes included) - Removes unused/duplicate timeval struct and DEBUG_TIMING definitions from SerialImp.c and SerialImp.h - Corrects fprintf call in SerialImp.cpp Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910b.patch Type: application/octet-stream Size: 9841 bytes Desc: not available URL: From Kapil_Gupta at hcl.in Thu Sep 10 10:25:29 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 10 Sep 2009 21:55:29 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, I am getting some problem with RXTX on macintosh (reading some data from the device attached to the usb port through usb to serial mechanism). I used the RXTX 2.1.7 then I got PortInUseException but after using 2.2pre it worked fine. But it works only for the first time, it hangs in the second time while opening the port. Please find the attached code. This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Thu Sep 10 13:00:14 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 22:00:14 +0300 Subject: [Rxtx] [Patch] Implement return value checking to file I/O calls Message-ID: Summary: The return value of some functions should always be used. For example, it is dangerous to not check the return value of a write(), read(), open(), fscanf() calls. This patch fixes such occurences in RXTX code. For example: unchecked read() call could result in later - and often seemingly unrelated - segfault due to undefined read buffer contents. After this patch the Linux build process is error/warning free even with gcc -Wall -Werror. Fixes: - Implemented return value checking to file I/O calls in SerialImp.c:fhs_lock(), uucp_lock() and is_device_locked() functions. - Added error recovery for fuserImp.c fscanf() calls. Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910c.patch Type: application/octet-stream Size: 3370 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Thu Sep 10 13:08:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 22:08:05 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> Hi Kapil, I believe this issue has been fixed in CVS version, but still exists in 2.2pre2 available from RXTX wiki. For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html As you've seen from the recent patches announced on this list, we are working very hard to make a new 2.2pre(?) release available. Meanwhile, you can compile your own RXTX binaries from CVS source. On Mac it should be exceptionally easy with new Xcode 3.x project files. Thank you for your patience, -- I > > I am getting some problem with RXTX on macintosh (reading some data > from the device attached to the usb port through usb to serial > mechanism). I used the RXTX 2.1.7 then I got PortInUseException but > after using 2.2pre it worked fine. But it works only for the first > time, it hangs in the second time while opening the port. From ilkka at myller.com Fri Sep 11 04:07:22 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 13:07:22 +0300 Subject: [Rxtx] [Patch] Windows build improvements (MinGW32, MSVC and LCC) Message-ID: <81D06766-8D51-485A-B2A2-624C8EA690BA@myller.com> Summary: Fixes various compiler warnings with Windows builds. Removes unused code blocks from compilation. After this patch the Windows build process is error/warning free with MinGW32, MSVC and LCC compilers - even with -Wall enabled. Does not fix: Latest LCC compiler version still fails even after this patch due to compiler trap error. Trap error does not specify source code location - it fails outputting SerialImp.obj binary. Compiling SerialImp.c without binary output works. Could this be a bug in LCC? Tested with clean RXTX source, latest standard LCC installation and with both Windows Vista SP1 x86 and Windows XP SP3 x86. Patch: The patch is against CVS (@2009/09/11). Attached patch file is in 'cvs diff -up' format. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090911.patch Type: application/octet-stream Size: 6673 bytes Desc: not available URL: From Kapil_Gupta at hcl.in Fri Sep 11 08:21:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Fri, 11 Sep 2009 19:51:24 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Ilkka, I tried getting the source code from the CVS but we could not able to do so, the CVS was not responding. Then we downloaded the 2.2 pre2 code and made the changes that are described in http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html but the problem didn't change. First time the device responds well and the second time it hangs. Did you see the code that we have sent to you, so that you can suggest if we are doing something wrong in our code. Again attaching if you have deleted that. Please suggest (does the CVS code can help rather using the patch provided by you?). Thanks, Kapil -----Original Message----- From: Ilkka Myller [mailto:ilkka at myller.com] Sent: Friday, September 11, 2009 12:38 AM To: Kapil Gupta Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Hi Kapil, I believe this issue has been fixed in CVS version, but still exists in 2.2pre2 available from RXTX wiki. For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html As you've seen from the recent patches announced on this list, we are working very hard to make a new 2.2pre(?) release available. Meanwhile, you can compile your own RXTX binaries from CVS source. On Mac it should be exceptionally easy with new Xcode 3.x project files. Thank you for your patience, -- I > > I am getting some problem with RXTX on macintosh (reading some data > from the device attached to the usb port through usb to serial > mechanism). I used the RXTX 2.1.7 then I got PortInUseException but > after using 2.2pre it worked fine. But it works only for the first > time, it hangs in the second time while opening the port. DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Fri Sep 11 09:33:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 18:33:33 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Hi Kapil, For CVS: Instructions at the old rxtx website are incorrect. Trent updated them, but to a wrong server address "qgang.org" -- the correct server is "qbang.org". Please follow instructions from rxtx wiki: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code About testing your code: When I have time (maybe this weekend), I'll test your code using Mac OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. What USB serial port you are using with your Mac? Something with FTDI chip? or maybe Prolific? What adapter driver version you are using? Just asking, so I can test with the same configuration. Meanwhile I suggest you: - Make sure you have the latest USB Serial adapter drivers, so we can eliminate past issues with those. - Check that you are not having multiple copies of librxtxSerial.jnilib (possibly different versions) in your java library path (=trouble;) - Check for any USB Serial adaptors kernel extension error messages in system log after testing your software (use Console.app to browse logs) -- I Kapil Gupta kirjoitti 11.9.2009 kello 17.21: > Hi Ilkka, > > I tried getting the source code from the CVS but we could not able > to do so, the CVS was not responding. Then we downloaded the 2.2 > pre2 code and made the changes that are described in http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html > but the problem didn't change. First time the device responds well > and the second time it hangs. > > Did you see the code that we have sent to you, so that you can > suggest if we are doing something wrong in our code. Again attaching > if you have deleted that. Please suggest (does the CVS code can help > rather using the patch provided by you?). > > Thanks, > Kapil > > -----Original Message----- > From: Ilkka Myller [mailto:ilkka at myller.com] > Sent: Friday, September 11, 2009 12:38 AM > To: Kapil Gupta > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second > time port open > > Hi Kapil, > > I believe this issue has been fixed in CVS version, but still exists > in 2.2pre2 available from RXTX wiki. > > For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html > > As you've seen from the recent patches announced on this list, we are > working very hard to make a new 2.2pre(?) release available. > > Meanwhile, you can compile your own RXTX binaries from CVS source. On > Mac it should be exceptionally easy with new Xcode 3.x project files. > > > Thank you for your patience, > > > -- > I > > >> >> I am getting some problem with RXTX on macintosh (reading some data >> from the device attached to the usb port through usb to serial >> mechanism). I used the RXTX 2.1.7 then I got PortInUseException but >> after using 2.2pre it worked fine. But it works only for the first >> time, it hangs in the second time while opening the port. > > > DISCLAIMER: > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential > and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of this > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > ----------------------------------------------------------------------------------------------------------------------- > From ilkka at myller.com Fri Sep 11 11:51:13 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 20:51:13 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Message-ID: <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> Ok, I debugged your code on Mac using USB-RS232 adapter + loopback adapter. My findings: there are no issues with RXTX in your code -- there are issues with threading and synchronization. Primary issue: you essentially lock the JVM main thread to 100% CPU usage with infinite loop: while (!processCompleted) { ; } Now.. I'm going to give you a bad advice, mostly because you have bigger threading issues there.. but we must continue somehow: A quick remedy to previous is: while (!processCompleted) { Thread.yield(); } Thread yielding gives other threads atleast a chance to run (and to processCompleted boolean to actually update in main thread context). What happens next is that your main-thread is allowed to continue and proceeds to closeConnection() call it otherwise would never reach. After that, connection closes properly.. main() method continues to "System.out.println(result);" and proceeds to exit JVM.. .. except.. Secondary issue: Exit is one thing JVM cant do since you have left a Timer thread hanging without proper closing in getData() method. Cancel it (uncomment that line) - and your code completes main() to a clean JVM exit. So, my advice to you is to focus on fixing threading, timers and synchronization. Design those well and everything works. Multithreading, done well or not, will not usually confuse RXTX ... but your own code might not be so lucky. -- I > > When I have time (maybe this weekend), I'll test your code using Mac > OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. >> >> Did you see the code that we have sent to you, so that you can >> suggest if we are doing something wrong in our code. Again >> attaching if you have deleted that. Please suggest (does the CVS >> code can help rather using the patch provided by you?). -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 11 15:19:26 2009 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 11 Sep 2009 17:19:26 -0400 Subject: [Rxtx] Can't run my Netbeans/Java s/w on a MAC Message-ID: <4AAABEDE.7020508@howardz.com> An HTML attachment was scrubbed... URL: From ilkka at myller.com Fri Sep 11 15:41:10 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 12 Sep 2009 00:41:10 +0300 Subject: [Rxtx] Can't run my Netbeans/Java s/w on a MAC In-Reply-To: <4AAABEDE.7020508@howardz.com> References: <4AAABEDE.7020508@howardz.com> Message-ID: <35D4BD73-B8CC-4DEE-A846-8858C9C9EBC7@myller.com> Hi, The bug that causes the segfault (invalid memory access) has been fixed (in CVS): http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html Next prerelease is coming (soon I hope), but the the 2.2pre2 fails when reopening the serial port on Mac OS X. -- I > > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] Jar > version = RXTX-2.2pre1 > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] native > lib Version = RXTX-2.2pre2 > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] Invalid > memory access of location 0x12b5e3938 rip=0x12955012f > 9/6/09 3:46:00 PM ReportCrash[6164] Saved crash report for java > [6162] version 13.0.0 (13.0.0) to /Users/myles/Library/Logs/ > DiagnosticReports/java_2009-09-06-154600_myles-PowerBook-PP-108.crash -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Fri Sep 11 20:15:31 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 11 Sep 2009 20:15:31 -0600 (MDT) Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Message-ID: On Fri, 11 Sep 2009, Ilkka Myller wrote: > Hi Kapil, > > For CVS: > > Instructions at the old rxtx website are incorrect. Trent updated them, but > to a wrong server address "qgang.org" -- the correct server is "qbang.org". > Please follow instructions from rxtx wiki: > > http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code The old website has been corrected. -- Trent Jarvi tjarvi at qbang.org From dvd at newfoundmarket.com Sat Sep 12 13:49:48 2009 From: dvd at newfoundmarket.com (DVD) Date: Sat, 12 Sep 2009 13:49:48 -0400 Subject: [Rxtx] RXTX on linux hang Message-ID: <4AABDF3C.2040908@newfoundmarket.com> Hello: I just did a fresh install of RXTZ on both Ubuntu and centos, Java version 6, update 12 I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with the Usage example from your website Two way communcation with the serial port I used the computer's serial port /dev/ttyS0, with UART 16550A the program simply hang. The port was opened and both input/output streamed were opened but the writing/reading are not working. Any help would be appreciated. I tried this program on windows and it worked fine. Thanks From ilkka at myller.com Sat Sep 12 17:31:26 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sun, 13 Sep 2009 00:31:26 +0300 Subject: [Rxtx] RXTX on linux hang In-Reply-To: <4AABDF3C.2040908@newfoundmarket.com> References: <4AABDF3C.2040908@newfoundmarket.com> Message-ID: Hi, It's very hard to say what could be wrong without more details. Can you tell me more about your Linux setup: - Output of: uname -a - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your test code running) - Output of: cat /proc/tty/driver/serial - Are you you testing with root privileges - What kind of device you are communicating with (or just a loopback dongle)? - Does your device expect some specific flow control and/or specific state of DTR/DSR signals? - Have you tried configuring those flow controls and other RS232 signals in your test code? Did they work? - Do other simple terminal programs work (easiest to try: screen /dev/ ttyS0 )? - What is the CPU usage (use 'top' or some other process monitor your like) of your test software when it "hangs"? I can try to duplicate your issue on Ubuntu 9.04 (both x86 and x86_64), Centos 5 (x86) and Debian 5.0 (x86). I'd prefer to test with the same kind of system you have.. Thanks, -- I > > I just did a fresh install of RXTZ on both Ubuntu and centos, Java > version 6, update 12 > I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with > the Usage example from > your website > > Two way communcation with the serial port > > > I used the computer's serial port /dev/ttyS0, with UART 16550A > > the program simply hang. The port was opened and both input/output > streamed were opened > but the writing/reading are not working. > > Any help would be appreciated. I tried this program on windows and > it worked fine. From dvd at newfoundmarket.com Sat Sep 12 23:20:14 2009 From: dvd at newfoundmarket.com (DVD) Date: Sat, 12 Sep 2009 23:20:14 -0400 Subject: [Rxtx] RXTX on linux hang In-Reply-To: References: <4AABDF3C.2040908@newfoundmarket.com> Message-ID: <4AAC64EE.7050904@newfoundmarket.com> Thank you very much for the steps. It is pin out problem. Again, Thanks. Ilkka Myller wrote: > Hi, > > It's very hard to say what could be wrong without more details. > Can you tell me more about your Linux setup: > > - Output of: uname -a > - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your > test code running) > - Output of: cat /proc/tty/driver/serial > - Are you you testing with root privileges > - What kind of device you are communicating with (or just a loopback > dongle)? > - Does your device expect some specific flow control and/or specific > state of DTR/DSR signals? > - Have you tried configuring those flow controls and other RS232 > signals in your test code? Did they work? > - Do other simple terminal programs work (easiest to try: screen > /dev/ttyS0 )? > - What is the CPU usage (use 'top' or some other process monitor your > like) of your test software when it "hangs"? > > > I can try to duplicate your issue on Ubuntu 9.04 (both x86 and > x86_64), Centos 5 (x86) and Debian 5.0 (x86). > I'd prefer to test with the same kind of system you have.. > > > Thanks, > > -- > I > > >> >> I just did a fresh install of RXTZ on both Ubuntu and centos, Java >> version 6, update 12 >> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with >> the Usage example from >> your website >> >> Two way communcation with the serial port >> >> >> >> I used the computer's serial port /dev/ttyS0, with UART 16550A >> >> the program simply hang. The port was opened and both input/output >> streamed were opened >> but the writing/reading are not working. >> >> Any help would be appreciated. I tried this program on windows and >> it worked fine. > From tjarvi at qbang.org Tue Sep 1 02:38:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 1 Sep 2009 02:38:40 -0600 (MDT) Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks Ilkka The problem should be resolved (confirmed from two locations). I'll be trying to hunt down a Snow Leopard box tomorrow evening as well. On Tue, 1 Sep 2009, Ilkka Myller wrote: > Hi, > > CVS server is reachable, but when trying anonymous login it replies: > > " > Fatal error, aborting. > anonymous: no such system user > " > > It seems that the anonymous cvs account is not yet properly configured on the > new system. > > -- > I > >> On Mon, 31 Aug 2009, Trent Jarvi wrote: >> >> The server has been beemed to another location for those experiencing >> routing problems. >> >> in bash: >> >> export CVSROOT=:pserver:anonymous at qbang.org:2401/var/cvs/cvsroot >> cvs login (no passwd) >> cvs co -r commapi-0-0-1 rxtx-devel >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Tue Sep 1 03:05:59 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 12:05:59 +0300 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks, The new CVS server works well :) I can also confirm that latest CVS version builds properly with unmodified Snow Leopard (Mac OS X 10.6) system: Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 gcc version 4.2.1 (Apple Inc. build 5646) Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) --> Resulting JNI library (Universal Binary): i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = 9d15fc488b301da8bf65b2c9456a7bbb --> Resulting JAR: RXTXComm.jar / 60942 bytes MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 Atleast it builds.. and probably works too. I have not tested that yet. -- I Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > The problem should be resolved (confirmed from two locations). I'll > be trying to hunt down a Snow Leopard box tomorrow evening as well. From jimmy.lee at emotum.com Tue Sep 1 05:07:19 2009 From: jimmy.lee at emotum.com (Jimmy Lee [emotum]) Date: Tue, 1 Sep 2009 21:07:19 +1000 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: <112685a90909010407i6054acb5tc2b12196797bfaf1@mail.gmail.com> Could we access to the binaries? Please :) 2009/9/1 Ilkka Myller > Thanks, > > The new CVS server works well :) > > I can also confirm that latest CVS version builds properly with unmodified > Snow Leopard (Mac OS X 10.6) system: > > Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_I386 i386 > gcc version 4.2.1 (Apple Inc. build 5646) > Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) > > > --> Resulting JNI library (Universal Binary): > > i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes > > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 > librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc > > MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = > 9d15fc488b301da8bf65b2c9456a7bbb > > > --> Resulting JAR: > > RXTXComm.jar / 60942 bytes > > MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 > > > > Atleast it builds.. and probably works too. I have not tested that yet. > > -- > I > > Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > > The problem should be resolved (confirmed from two locations). I'll be >> trying to hunt down a Snow Leopard box tomorrow evening as well. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Tue Sep 1 06:21:28 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Tue, 1 Sep 2009 08:21:28 -0400 (EDT) Subject: [Rxtx] Snow Leopard binaries Message-ID: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> +1 for binaries - pretty please with sugar on top... -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com From fredm at alum.mit.edu Tue Sep 1 06:24:17 2009 From: fredm at alum.mit.edu (Fred G. Martin) Date: Tue, 1 Sep 2009 08:24:17 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> Message-ID: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> You can find one here: http://iharder.sourceforge.net/current/java/ Also, you need to add yourself (any rxtx user) to the uucp group. Niutils don't exist, but dscl is a replacement. There is info for using it here: http://aplawrence.com/MacOSX/directory_services.html Fred On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Tue Sep 1 07:03:37 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Tue, 1 Sep 2009 18:33:37 +0530 Subject: [Rxtx] Help for RXTX on mac Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time I am able to read the device but on second time, it hangs on COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then it was showing the PortInUseException, I replaced the RXTX library to 2.2Pre1 so it is showing this problem. Is this is a problem with RXTX on Mac? Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: From ilkka at myller.com Tue Sep 1 07:57:06 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 16:57:06 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:02:31 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:02:31 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:43:49 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:43:49 +0300 Subject: [Rxtx] Help for RXTX on mac In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE@myller.com> Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Arseneau at Sun.COM Tue Sep 1 08:51:32 2009 From: Eric.Arseneau at Sun.COM (Eric Arseneau) Date: Tue, 01 Sep 2009 07:51:32 -0700 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24@sun.com> Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 09:24:30 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 18:24:30 +0300 Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D@myller.com> Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Thu Sep 3 02:50:16 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Thu, 3 Sep 2009 10:50:16 +0200 Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s From Kapil_Gupta at hcl.in Thu Sep 3 06:52:21 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:22:21 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From Kapil_Gupta at hcl.in Thu Sep 3 07:15:19 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:45:19 +0530 Subject: [Rxtx] Rxtx Digest, Vol 25, Issue 3 In-Reply-To: References: Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C50BB@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi myller, I have attached the code with the mail. Please help me if I am doing something wrong in it. Thanks & Regards, Kapil Gupta -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of rxtx-request at qbang.org Sent: Thursday, September 03, 2009 4:15 PM To: rxtx at qbang.org Subject: Rxtx Digest, Vol 25, Issue 3 Send Rxtx mailing list submissions to rxtx at qbang.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qbang.org/mailman/listinfo/rxtx or, via email, send a message with subject or body 'help' to rxtx-request at qbang.org You can reach the person managing the list at rxtx-owner at qbang.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Rxtx digest..." Today's Topics: 1. Re: Snow Leopard binaries (Ilkka Myller) 2. Re: Snow Leopard binaries (Ilkka Myller) 3. Re: Help for RXTX on mac (Ilkka Myller) 4. Re: Snow Leopard binaries (Eric Arseneau) 5. Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters (Ilkka Myller) 6. RXTX multiple crashes (Kjetil ?ster?s) 7. RXTX 2.2Pre + MacMini+ Deadlock while second time port open (Kapil Gupta) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Sep 2009 16:57:06 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 1 Sep 2009 17:02:31 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <55EC133D-DC83-45A3-849C-02714904D580 at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 1 Sep 2009 17:43:49 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Help for RXTX on mac Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Tue, 01 Sep 2009 07:51:32 -0700 From: Eric Arseneau Cc: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24 at sun.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 1 Sep 2009 18:24:30 +0300 From: Ilkka Myller To: rxtx Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Thu, 3 Sep 2009 10:50:16 +0200 From: Kjetil ?ster?s To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s ------------------------------ Message: 7 Date: Thu, 3 Sep 2009 18:22:21 +0530 From: Kapil Gupta To: "rxtx at qbang.org" Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059 at NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset="us-ascii" Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: ------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx End of Rxtx Digest, Vol 25, Issue 3 *********************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From ilkka at myller.com Thu Sep 3 11:17:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 3 Sep 2009 20:17:27 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <4520677F-E8F0-46F5-B4AD-3AD3A7C2AED3@myller.com> Hi Kapil, The code is incomplete and I did not find anything I could to test/ debug with this. I also tried to find the actual serial port opening, but found only a call to missing method which creates the SerialPort object (?): serialPort = getSerialPortConnection( COMPort, this.readEvent.getDeviceName(), SerialCommConfig.DEVICE1[SerialCommConfig.TIMEOUT], SerialCommConfig.DEVICE1[SerialCommConfig.BAUDRATE], SerialCommConfig.DEVICE1[SerialCommConfig.DATABITS], SerialCommConfig.DEVICE1[SerialCommConfig.STOPBITS], SerialCommConfig.DEVICE1[SerialCommConfig.PARITY] ); The class SerialCommConfig is missing too. If this is a part of the actual code you are using, please note that you are not actually closing the serial port. The call to close() method is commented out: try { // serialPort.close(); } catch (Exception ex) { ex.printStackTrace(); } Re-opening of the serial port wont work if you haven't properly closed it first. -- I > > I am using RXTX on Macintosh to communicate to my device. First time > the device responds well but on second time, it hangs on > COMPort.open (name, timeout). > > I have attached the source code in a file. Please help me. > > Thanks & Best Regards, > Kapil -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorton at intellimec.com Thu Sep 3 11:37:55 2009 From: dmorton at intellimec.com (Daniel Morton) Date: Thu, 3 Sep 2009 13:37:55 -0400 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. (I haven't tried previous version though). Daniel Morton Java/J2EE Developer Tel +1 519.745.8887 x4331 Email dmorton at intellimec.com www.intellimec.com | www.iLane.com | www.drivesync.com Intelligent Mechatronic Systems Inc. 435 King Street North Waterloo, ON N2J 2Z5 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s Sent: Thursday, September 03, 2009 4:50 AM To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. From alexanderkiel at gmx.net Fri Sep 4 02:29:15 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 10:29:15 +0200 Subject: [Rxtx] Official Javadoc Location Message-ID: <1252052955.4025.80.camel@T61-KIEL> Hi List, I wasn't able to find an official location of RXTX Javadoc accessible over HTTP. Maybe someone can link me to it. If there is no such location, I would like to see one. I like to link from my own Javadoc to such a location. Thanks Alexander - e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:19:25 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:19:25 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> Message-ID: <1252055965.4025.84.camel@T61-KIEL> Hi Michael, thanks for the pointer. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 09:48 +0100, Michael Tandy wrote: > RxTx javadoc: http://users.frii.com/jarvi/rxtx/doc/index.html > Javax interface RxTx duplicates javadoc: > http://java.sun.com/products/javacomm/reference/api/index.html > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:22:14 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:22:14 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> Message-ID: <1252056134.4025.87.camel@T61-KIEL> Hi Eike, thanks, but I need a direct package pointer so that Javadoc will link the gnu.io packages automatically to the right location. Michael has pointed me to http://users.frii.com/jarvi/rxtx/doc/index.html which has the gnu.io packages. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 11:04 +0200, Eike Hinderk J?rrens wrote: > Hi Alexander, > it seems to me that RXTX is implementing this API: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Kind regards, > Eike > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kjetilos at gmail.com Fri Sep 4 03:43:41 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 11:43:41 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> Message-ID: <7a803d460909040243ke4449ecucbe2cd8b15761746@mail.gmail.com> Hi Daniel, This is interesting, what type of application are you making? Is there a lot of signaling on different COM ports at the same time in your application? In our application we have 11 devices connected to different COM ports, 9 of these are in active use when the application is running. I'm wondering how to use the RXTX library version 2.1.7 in this scenario without causing it to crash. After adding more signaling on the COM ports in our application we have now experienced other crashes and it is natural to think that it has something to do with our way of using RXTX from several threads at the same time. So my question is are there any methods like read/write/flush/close that are not thread safe and should be handled with care? And similarly is the RXTXPort.SerialInputStream and RXTXPort.SerialOutputStream thread safe? 2009/9/3 Daniel Morton : > I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. ?(I haven't tried previous version though). > > Daniel Morton > Java/J2EE Developer > > Tel ? ?+1 519.745.8887 x4331 > Email ? ?dmorton at intellimec.com > > > www.intellimec.com ?| ?www.iLane.com ?| ?www.drivesync.com > > > > Intelligent Mechatronic Systems Inc. > 435 King Street North Waterloo, ON N2J 2Z5 > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s > Sent: Thursday, September 03, 2009 4:50 AM > To: rxtx at qbang.org > Subject: [Rxtx] RXTX multiple crashes > > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x7d0d] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0ce75800): ?JavaThread "Y Worker" daemon > [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 > > Registers: > EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 > ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 > EIP=0x10007d0d, EFLAGS=0x00010202 > > Top of Stack: (sp=0x0d7ff6d8) > 0x0d7ff6d8: ? 0d7ff700 00000000 00000000 00000000 > 0x0d7ff6e8: ? 02a2eae8 00000123 00002958 0d7ff718 > 0x0d7ff6f8: ? 7c830887 7c90d28a 7c8664b5 00000e2c > 0x0d7ff708: ? 00002958 00000000 00000000 7c90cffa > 0x0d7ff718: ? 7c809bdb 00002958 0d7ff758 00000e40 > 0x0d7ff728: ? 00002958 02bd0468 0ce75800 080e4ee0 > 0x0d7ff738: ? 00000000 00000000 00000000 00000000 > 0x0d7ff748: ? 00000000 00000000 00000014 7c90d09a > > Instructions: (pc=0x10007d0d) > 0x10007cfd: ? 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 > 0x10007d0d: ? 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 > > > Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x7d0d] > J ?gnu.io.RXTXPort.nativeDrain(Z)Z > J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > ... > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x9c55] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0cddf400): ?JavaThread "XXX Worker" daemon > [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 > > Registers: > EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 > ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 > EIP=0x10009c55, EFLAGS=0x00010206 > > Top of Stack: (sp=0x0bb8f830) > 0x0bb8f830: ? 00000000 00000000 c0000005 00000000 > 0x0bb8f840: ? 00000000 00f1f0a5 00000002 00000000 > 0x0bb8f850: ? 003a0100 0001003f 0bb8fb20 0b9ff918 > 0x0bb8f860: ? 00000000 00000000 0bb8fb68 0bb8fb20 > 0x0bb8f870: ? 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 > 0x0bb8f880: ? 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 > 0x0bb8f890: ? 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 > 0x0bb8f8a0: ? 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 > > Instructions: (pc=0x10009c55) > 0x10009c45: ? 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff > 0x10009c55: ? 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 > > > Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x9c55] > C ?[rxtxSerial.dll+0xa05e] > J ?gnu.io.RXTXPort.readByte()I > J ?gnu.io.RXTXPort$SerialInputStream.read()I > J ?java.io.FilterInputStream.read()I > ... > > -- > Kjetil ?ster?s > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kjetil ?ster?s From tjarvi at qbang.org Fri Sep 4 06:00:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Sep 2009 06:00:40 -0600 (MDT) Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x7d0d] > J gnu.io.RXTXPort.nativeDrain(Z)Z > J gnu.io.RXTXPort$SerialOutputStream.flush()V > Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x9c55] > C [rxtxSerial.dll+0xa05e] > J gnu.io.RXTXPort.readByte()I > J gnu.io.RXTXPort$SerialInputStream.read()I RXTX 2.1-7 has concurrency issues that will show upon multicore systems. These should be resolved in the 2.2 pre release. A user application could synchronize the read/write/open/close calls while using 2.1 to avoid the concurrency issue. The flush is probably following a write while the readByte is coming from read(byte b). The bugs existed in rxtx for a long time. I assume changes in the JVM and the presence of multicore systems exposed the issues. -- Trent Jarvi tjarvi at qbang.org From kjetilos at gmail.com Fri Sep 4 06:33:33 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 14:33:33 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <7a803d460909040533n1caf240y8168477a578bc45c@mail.gmail.com> Den 4. september 2009 14.00 skrev Trent Jarvi f?lgende: > > > On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > >> Hi >> >> We are using RXTX version 2.1.7 actively and lately we are having some >> issues with the RXTX library crashing. We are running a windows xp >> system with multiple COM ports where each COM port have a serial >> device connected. Lately we have increased the amount of signaling >> done over the COM ports and we are experiencing several odd crashes. I >> tried to search the mailinglist for something similar but was unable >> to find anything. At one time the RXTX crashed in the >> gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the >> gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack >> traces if someone is interested in having a look. Has anyone seen the >> same crashes? and does anyone know what can cause such crash? >> >> >> Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x7d0d] >> J ?gnu.io.RXTXPort.nativeDrain(Z)Z >> J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > >> Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x9c55] >> C ?[rxtxSerial.dll+0xa05e] >> J ?gnu.io.RXTXPort.readByte()I >> J ?gnu.io.RXTXPort$SerialInputStream.read()I > > > RXTX 2.1-7 has concurrency issues that will show upon multicore systems. > These should be resolved in the 2.2 pre release. ?A user application could > synchronize the read/write/open/close calls while using 2.1 to avoid the > concurrency issue. > > The flush is probably following a write while the readByte is coming from > read(byte b). > > The bugs existed in rxtx for a long time. ?I assume changes in the JVM and > the presence of multicore systems exposed the issues. > Ok, so we should look more into using a newer version of RXTX. The current version from the webpage is 2.2pre2, what is the stability status of this version. Is it good enough for use in a production environment? -- Kjetil ?ster?s From martinezrodolfo at gmail.com Fri Sep 4 13:39:57 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Fri, 4 Sep 2009 15:09:57 -0430 Subject: [Rxtx] Problem with data available event Message-ID: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Hello list members. I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a serial port USB adapter to communicate with an electronical inmunoassay analyzer. The program works porperly with one model of the analyzer series. It defines a protocol which every message sent should be replied with an ACK in order to continue with the communication. Now we are trying to communicate with another model of the same brand and series wich in theory should be much of the same of what was previously done. Unfortunately, that is not the case. The problem with this connection is that it never fires the Data Available serial port event. Is like if nothing was being received in the input stream. The following code always prints zero when the equipment should be transmitting. ----------------------- beginning of sample code ---------------------------------- SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", 10000); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); int len = 0; byte[] readBuffer = new byte[8]; while (true) { len = in.read(readBuffer); System.out.println(len); writer.writeACK(); // writing ACK to analyzer } ----------------------- end of sample code ------------------------------------------ We know that the analyzer is transmitting because HyperTerminal does shows the proper output. In fact, after running the above code and connecting via Hyperterminal all data is received in one block. Is like the data sent from the analyzer is being held somewhere in the way. Sniffing at the serial port, noticed that IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this helps to find what might be wrong or not, but here they are: On Hyperterminal: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 XonLimit:80 XoffLimit:200 On Java: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 XonLimit:0 XoffLimit:0 Thanks in advance for your help. Rodolfo M From ilkka at myller.com Sat Sep 5 04:36:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 5 Sep 2009 13:36:27 +0300 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <121198EE-65A4-463B-ACC7-29FFB9855B2C@myller.com> Hi Rodolfo, By default RXTX does not enable any flow control for the serial port. Please check what flow control you have active in HyperTerminal when you are able to receive data and then use the same flow control with RXTX serial port: serialPort.setFlowControlMode(int flowcontrol); Possible flowcontrol flags are (from SerialPort class) FLOWCONTROL_NONE FLOWCONTROL_RTSCTS_IN FLOWCONTROL_RTSCTS_OUT FLOWCONTROL_XONXOFF_IN FLOWCONTROL_XONXOFF_OUT For example, you can try enabling RTS/CTS hardware flow control. Note the bitwise OR operator ' | ': serialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Also if your device requires RTS/CTS flow control make sure you have fully connected serial cable (not just RX, TX, GND for example, but also RTS, CTS, DTR). One thing you might want to check is the state of DTR (Data Terminal Ready). Some devices wait for the DTR signal before they send any data. You can enable or disable DTR signal (high/low) with: serialPort.setDTR( boolean state ); -- I > Hello list members. > > I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a > serial port USB adapter to communicate with an electronical > inmunoassay analyzer. The program works porperly with one model of the > analyzer series. It defines a protocol which every message sent should > be replied with an ACK in order to continue with the communication. > Now we are trying to communicate with another model of the same brand > and series wich in theory should be much of the same of what was > previously done. Unfortunately, that is not the case. The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. > > ----------------------- beginning of sample code > ---------------------------------- > SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", > 10000); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > InputStream in = serialPort.getInputStream(); > OutputStream out = serialPort.getOutputStream(); > > int len = 0; > byte[] readBuffer = new byte[8]; > while (true) { > len = in.read(readBuffer); > System.out.println(len); > > writer.writeACK(); // writing ACK to analyzer > } > ----------------------- end of sample code > ------------------------------------------ > > We know that the analyzer is transmitting because HyperTerminal does > shows the proper output. In fact, after running the above code and > connecting via Hyperterminal all data is received in one block. Is > like the data sent from the analyzer is being held somewhere in the > way. Sniffing at the serial port, noticed that > IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this > helps to find what might be wrong or not, but here they are: > > On Hyperterminal: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 > XonLimit:80 XoffLimit:200 > > On Java: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 > XonLimit:0 XoffLimit:0 > > > Thanks in advance for your help. > Rodolfo M > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.weber99 at gmx.net Sun Sep 6 13:51:12 2009 From: karl.weber99 at gmx.net (Karl Weber) Date: Sun, 6 Sep 2009 21:51:12 +0200 Subject: [Rxtx] Cannot create lock file Message-ID: <200909062151.12228.karl.weber99@gmx.net> Hi, I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an opensuse repository as well as from the homepage of the rxtx project. I have already added the user to the group uucp, however, it does not have any effect. What else do I have to do to make it work? (It does work with user root, though.) The error message is: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL Thanks in advance, Karl From tjarvi at qbang.org Sun Sep 6 13:51:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 6 Sep 2009 13:51:42 -0600 (MDT) Subject: [Rxtx] Cannot create lock file In-Reply-To: <200909062151.12228.karl.weber99@gmx.net> References: <200909062151.12228.karl.weber99@gmx.net> Message-ID: On Sun, 6 Sep 2009, Karl Weber wrote: > Hi, > > I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an > opensuse repository as well as from the homepage of the rxtx project. > > I have already added the user to the group uucp, however, it does not have > any effect. What else do I have to do to make it work? (It does work with > user root, though.) > > The error message is: > > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to > create lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > > Thanks in advance, Karl Look at the group that owns /var/lock with ls -ld /var/lock The following should work as a user when they are in the correct group: touch /var/lock/test && rm -f /var/lock/test -- Trent Jarvi tjarvi at qbang.org From Luca.Catoni at sysdat.it Mon Sep 7 06:32:42 2009 From: Luca.Catoni at sysdat.it (Luca Catoni) Date: Mon, 7 Sep 2009 14:32:42 +0200 Subject: [Rxtx] time-out implementation Message-ID: I need to implement a simple timer class to manage time-out in my RS-232 serial communication with a remote device using the rxtx library. The functions that the timer should have are start(), and reset() and start() method must throw an exception (TimeoutException) when it expires. I am not an expert in concurrent programming and I do not have much knowledge on threads. myTimer.setExpirationTime(myvalue); ? public void serialEvent(SerialPortEvent event) { if (event.getEventType() == SerialPortEvent.OUTPUT_BUFFER_EMPTY) { // transmission ? out.write(?); try{ myTimer.start(); }catch(TimeoutException te){ myTimer.reset(); ? } ? if (event.getEventType() == SerialPortEvent.DATA_AVAILABLE) { // receiving in.read(?); if (mycondition){ myTimer.stop();//ok, timer NOT expired myTimer.reset();//now I can call start() method again in //transmission to restart my timer when I //have to transmit next data } Can anyone help me to implement the class MyTimer? thanks in advance. -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Mon Sep 7 06:49:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Mon, 7 Sep 2009 18:19:24 +0530 Subject: [Rxtx] 2.2Pre + MacMini+ Deadlock while second time port Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E22FB6F@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, Please find the updated code (close call was commented by mistake). This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From michael.erskine at ketech.com Mon Sep 7 09:13:03 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 7 Sep 2009 16:13:03 +0100 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Rodolfo Mart?nez > Subject: [Rxtx] Problem with data available event > The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. Hi Rodolfo, The sample code you provided doesn't implement or register any event listeners. Regards, Michael Erskine. From martinezrodolfo at gmail.com Mon Sep 7 10:21:22 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Mon, 7 Sep 2009 11:51:22 -0430 Subject: [Rxtx] Problem with data available event In-Reply-To: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> Message-ID: <30eacee0909070921l7f285765ue2c661963183fd2b@mail.gmail.com> On Mon, Sep 7, 2009 at 10:43 AM, Michael Erskine wrote: > Hi Rodolfo, > The sample code you provided doesn't implement or register any event listeners. > > Regards, > Michael Erskine. Hi Michael, I didn't write the event listeners declaration on the sample code for simplicity, but I do implement them on my real code. I should have mentioned it on the sample code anyway... my bad. I haven't had access to the device I'm trying to connect, but tomorrow will. And hope that with the explanation of Ilkka Myller will succeed this time. Thanks for your attention. Rodolfo M From ajmas at sympatico.ca Mon Sep 7 16:58:13 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 7 Sep 2009 18:58:13 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" I noticed in the page you posted posted you indicated that you patched two files. Did you submit the changes to Jarvi, so they could be included in the main code branch? Andr? From tjarvi at qbang.org Mon Sep 7 16:57:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Sep 2009 16:57:53 -0600 (MDT) Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On Mon, 7 Sep 2009, Andre-John Mas wrote: > > On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > >> Sorry, my rudeness was not intentional (a typo). >> Lets try again.. ;) >> >> "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > I noticed in the page you posted posted you indicated that you patched two > files. Did you submit the changes to Jarvi, so they could be included in the > main code branch? > Hi Andr? Ilkka is working with us to get changes in. I'm not sure about those two patches which may already be in CVS. I'll let him answer that. I've given him write access to CVS and asked him to cc the list non whitespace changes when they are ready. Right now he is asking questions off the list regarding cleaning up the Mac and w32 build files. -- Trent Jarvi tjarvi at qbang.org From nsp25 at cornell.edu Mon Sep 7 21:17:45 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Mon, 7 Sep 2009 23:17:45 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: (Sorry if this is a double post, but I sent my original message without subscribing, and since this is an urgent problem, I thought I'd resend after subscribing to bypass the moderator limbo zone) Hi all, I've asked my question on StackOverflow already, so rather than copy-paste the question here, I'd like to redirect you there . Short version, I am no longer able to receive anything over RS-232 with RXTX, but other programs work fine. I'm definitely sending things, because when I connect with a different program, all the responses to the commands I sent via RXTX arrive all at once. Everything was fine in the spring, so what could have happened? Windows update? -Nate -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.j.tandy at warwick.ac.uk Tue Sep 8 01:30:48 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Tue, 8 Sep 2009 08:30:48 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> OK, so: 1. It worked in spring but has stopped doing so and 2. The data all arrives at once when you start hyperterminal. Is it possible you're using a different serial cable to connect to the device, compared to the one you were using in spring? If so, the issue might be hardware flow control - that is, your device might be buffering data because it can't transmit it until your computer sets 'DTR' or 'RTS' or something like that. One way of bypassing hardware flow control is by using cables which cross over certain wires so that the right signals are always being sent; it's possible your old cable had these connections but your current cable doesn't have them. If you can find the old cable, you could put it back in and see if that fixes things? 2009/9/8 Nathaniel S. Parsons : > (Sorry if this is a double post, but I sent my original message without > subscribing, and since this is an urgent problem, I thought I'd resend after > subscribing to bypass the moderator limbo zone) > > Hi all, > > I've asked my question on StackOverflow already, so rather than copy-paste > the question here, I'd like to redirect you there. > > Short version, I am no longer able to receive anything over RS-232 with > RXTX, but other programs work fine. I'm definitely sending things, because > when I connect with a different program, all the responses to the commands I > sent via RXTX arrive all at once. > > Everything was fine in the spring, so what could have happened? Windows > update? > > -Nate > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Tue Sep 8 01:50:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 8 Sep 2009 10:50:33 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <111FEC9A-26BA-435C-BABC-314C7E4F23E5@myller.com> Hi all, Patches applied to the 2.1.7 binaries distributed by Robert Harder (http://iharder.sourceforge.net/current/java/ ) are already in the 2.2. Actually in 2.2 the issue with integer types handling seems to be fixed even more extensively than that single patch to 2.1.7 originally did. And yes, Trent has granted me CVS commit access. Thank you. First thing I'm going to focus on is the code quality and clean up: unused variables, invalid pointer usage etc.. Most of this just causing compile warnings - some harmless and some have potential for causing runtime problems. Instead of just blindly committing new changes to CVS, I've been discussing with Trent about the way things have been done in the RXTX CVS before. (how to handle white space patches, what needs to be discussed with the list first, proper locations for new files/ directories/subprojects, "the way things are done in RXTX"). But patches are coming and bugs will be fixed. I hope everyone will continue to submit the bugs they discover to this mailing list. Most important thing is to provide enough info (code;) so that the issue can be duplicated and eventually fixed. -- I > > > On Mon, 7 Sep 2009, Andre-John Mas wrote: >> >> I noticed in the page you posted posted you indicated that you >> patched two files. Did you submit the changes to Jarvi, so they >> could be included in the main code branch? >> > > Ilkka is working with us to get changes in. I'm not sure about > those two patches which may already be in CVS. I'll let him answer > that. > > I've given him write access to CVS and asked him to cc the list non > whitespace changes when they are ready. Right now he is asking > questions off the list regarding cleaning up the Mac and w32 build > files. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 15:35:19 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 17:35:19 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: Thanks for the response. I'll try to get to the electronics store tomorrow to get more serial cables, even if it isn't the problem. I am using a different serial cable than I was in the spring. It's actually a Male/Female cable with a female-female adapter since the old cables aren't around anymore. The hardware's manual says nothing except to use a "Straight cable" but I figured that if it worked in HyperTerminal, it should work in RXTX, right? Anyways, I've also noticed some things that are different between HyperTerminal, RXTX, and a separate program I found that communicates with the device (but doesn't do what I want, which is why I'm rolling my own program) HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and DTR indicators are green Other program - not sure what settings it thinks it's using, but only SPM's RTS indicator is green RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators are on. >From Serial Port Monitor's help files (paraphrased): the indicators display the state of the serial control lines RTS - Request To Send CTS - Clear To Send DTR - Data Terminal Ready Could this be related to the problem? -Nate On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > OK, so: > > 1. It worked in spring but has stopped doing so and > 2. The data all arrives at once when you start hyperterminal. > > Is it possible you're using a different serial cable to connect to the > device, compared to the one you were using in spring? > > If so, the issue might be hardware flow control - that is, your device > might be buffering data because it can't transmit it until your > computer sets 'DTR' or 'RTS' or something like that. > > One way of bypassing hardware flow control is by using cables which > cross over certain wires so that the right signals are always being > sent; it's possible your old cable had these connections but your > current cable doesn't have them. If you can find the old cable, you > could put it back in and see if that fixes things? > > > 2009/9/8 Nathaniel S. Parsons : > > (Sorry if this is a double post, but I sent my original message without > > subscribing, and since this is an urgent problem, I thought I'd resend > after > > subscribing to bypass the moderator limbo zone) > > > > Hi all, > > > > I've asked my question on StackOverflow already, so rather than > copy-paste > > the question here, I'd like to redirect you there. > > > > Short version, I am no longer able to receive anything over RS-232 with > > RXTX, but other programs work fine. I'm definitely sending things, > because > > when I connect with a different program, all the responses to the > commands I > > sent via RXTX arrive all at once. > > > > Everything was fine in the spring, so what could have happened? Windows > > update? > > > > -Nate > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 18:57:58 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 20:57:58 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: I added a call to setRTS() but nothing changed in Serial Port Monitor, no matter what the argument was. Is this a bug, or did I call the wrong function? I tried to find the c code behind this function, and I think I found it in rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong to me. Am I looking at the right function or is the problem somewhere else? -Nate On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons wrote: > Thanks for the response. I'll try to get to the electronics store tomorrow > to get more serial cables, even if it isn't the problem. > > I am using a different serial cable than I was in the spring. It's actually > a Male/Female cable with a female-female adapter since the old cables aren't > around anymore. The hardware's manual says nothing except to use a "Straight > cable" but I figured that if it worked in HyperTerminal, it should work in > RXTX, right? > > Anyways, I've also noticed some things that are different between > HyperTerminal, RXTX, and a separate program I found that communicates with > the device (but doesn't do what I want, which is why I'm rolling my own > program) > > HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and > DTR indicators are green > Other program - not sure what settings it thinks it's using, but only SPM's > RTS indicator is green > RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators > are on. > > From Serial Port Monitor's help files (paraphrased): the indicators display > the state of the serial control lines > > RTS - Request To Send > CTS - Clear To Send > DTR - Data Terminal Ready > > Could this be related to the problem? > > -Nate > > > On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > >> OK, so: >> >> 1. It worked in spring but has stopped doing so and >> 2. The data all arrives at once when you start hyperterminal. >> >> Is it possible you're using a different serial cable to connect to the >> device, compared to the one you were using in spring? >> >> If so, the issue might be hardware flow control - that is, your device >> might be buffering data because it can't transmit it until your >> computer sets 'DTR' or 'RTS' or something like that. >> >> One way of bypassing hardware flow control is by using cables which >> cross over certain wires so that the right signals are always being >> sent; it's possible your old cable had these connections but your >> current cable doesn't have them. If you can find the old cable, you >> could put it back in and see if that fixes things? >> >> >> 2009/9/8 Nathaniel S. Parsons : >> > (Sorry if this is a double post, but I sent my original message without >> > subscribing, and since this is an urgent problem, I thought I'd resend >> after >> > subscribing to bypass the moderator limbo zone) >> > >> > Hi all, >> > >> > I've asked my question on StackOverflow already, so rather than >> copy-paste >> > the question here, I'd like to redirect you there. >> > >> > Short version, I am no longer able to receive anything over RS-232 with >> > RXTX, but other programs work fine. I'm definitely sending things, >> because >> > when I connect with a different program, all the responses to the >> commands I >> > sent via RXTX arrive all at once. >> > >> > Everything was fine in the spring, so what could have happened? Windows >> > update? >> > >> > -Nate >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Tue Sep 8 21:54:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 21:54:26 -0600 (MDT) Subject: [Rxtx] rxtx is moving to the clouds Message-ID: rxtx is moving onto a cloud server. You may notice short outages as things move around. So far the following is done. http://rxtx.qbang.org (will redirect rxtx.org there for 2.2) http://bugzilla.qbang.org (bugs) The mail-list is tomorrow night. CVS and FTP will be last. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 8 22:03:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 22:03:26 -0600 (MDT) Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: On Tue, 8 Sep 2009, Nathaniel S. Parsons wrote: > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? Hi Nathaniel, That depends upon what you are running. WinCE is for embedded windows. The Windows source is in src/termios.c (called from src/SerialImp.c). -- Trent Jarvi tjarvi at qbang.org From m.j.tandy at warwick.ac.uk Wed Sep 9 03:27:10 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 10:27:10 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> I had a similar problem a while ago - hardware that would work with Hyperterminal but not with Rxtx. I don't know if this is a bug in RxTx or not - I tried to find where in the RxTx source code those functions are actually implemented - I got as far as the ioctl function in termios.c, where the TIOCMSET case sets the MSR byte in the termios struct, but I can't figure out where that gets written to the dcb struct's fDtrControl dword. It could be a bug, or it could just be me missing something. In any case, at the time I had this problem I wasn't equipped to debug RxTx so instead I created a special cable to satisfy the hardware's flow control while leaving the data connection straight through. Here's how I connected it: At the female end of the cable (i.e. the hardware I was connecting to) I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. I connected the ground and data pins straight through - that is, pin 5 female end to pin 5 male end, pin 2 female end to pin 2 male end, pin 3 female end to pin 3 male end. Anyway, using that cable bypassed the hardware's flow control, and got RxTx working just as well as HyperTerminal - although I slowed down my communication to make sure I didn't encounter a situation where the flow control would have come into effect, as I had bypassed it! Hope that helps. 2009/9/9 Nathaniel S. Parsons : > I added a call to setRTS() but nothing changed in Serial Port Monitor, no > matter what the argument was. Is this a bug, or did I call the wrong > function? > > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? > > -Nate > > On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > wrote: >> >> Thanks for the response. I'll try to get to the electronics store tomorrow >> to get more serial cables, even if it isn't the problem. >> >> I am using a different serial cable than I was in the spring. It's >> actually a Male/Female cable with a female-female adapter since the old >> cables aren't around anymore. The hardware's manual says nothing except to >> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >> should work in RXTX, right? >> >> Anyways, I've also noticed some things that are different between >> HyperTerminal, RXTX, and a separate program I found that communicates with >> the device (but doesn't do what I want, which is why I'm rolling my own >> program) >> >> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >> DTR indicators are green >> Other program - not sure what settings it thinks it's using, but only >> SPM's RTS indicator is green >> RXTX - no matter what flow control I set, only SPM's CTS and DTR >> indicators are on. >> >> From Serial Port Monitor's help files (paraphrased): the indicators >> display the state of the serial control lines >> >> RTS - Request To Send >> CTS - Clear To Send >> DTR - Data Terminal Ready >> >> Could this be related to the problem? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> wrote: >>> >>> OK, so: >>> >>> 1. It worked in spring but has stopped doing so and >>> 2. The data all arrives at once when you start hyperterminal. >>> >>> Is it possible you're using a different serial cable to connect to the >>> device, compared to the one you were using in spring? >>> >>> If so, the issue might be hardware flow control - that is, your device >>> might be buffering data because it can't transmit it until your >>> computer sets 'DTR' or 'RTS' or something like that. >>> >>> One way of bypassing hardware flow control is by using cables which >>> cross over certain wires so that the right signals are always being >>> sent; it's possible your old cable had these connections but your >>> current cable doesn't have them. If you can find the old cable, you >>> could put it back in and see if that fixes things? >>> >>> >>> 2009/9/8 Nathaniel S. Parsons : >>> > (Sorry if this is a double post, but I sent my original message without >>> > subscribing, and since this is an urgent problem, I thought I'd resend >>> > after >>> > subscribing to bypass the moderator limbo zone) >>> > >>> > Hi all, >>> > >>> > I've asked my question on StackOverflow already, so rather than >>> > copy-paste >>> > the question here, I'd like to redirect you there. >>> > >>> > Short version, I am no longer able to receive anything over RS-232 with >>> > RXTX, but other programs work fine. I'm definitely sending things, >>> > because >>> > when I connect with a different program, all the responses to the >>> > commands I >>> > sent via RXTX arrive all at once. >>> > >>> > Everything was fine in the spring, so what could have happened? Windows >>> > update? >>> > >>> > -Nate >>> > >>> > _______________________________________________ >>> > Rxtx mailing list >>> > Rxtx at qbang.org >>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>> > >>> > >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Wed Sep 9 03:54:45 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 12:54:45 +0300 Subject: [Rxtx] Xcode 3.x project available in CVS Message-ID: Hi everyone, I've just committed Apple Xcode 3.x (preferably 3.2) compatible project to CVS. The project can be used to develop and build Mac OS X 10.5+ compatible Universal Binary JNI library and RXTXcomm.jar. It's does not have dependencies to existing Autotools based build scripts - only standard Xcode installation is required. The older Xcode 2.x project is still there, but please note that it's not compatible with newer Xcode versions due to its dependency to deprecated Jam build system. The new project is available in rxtx-devel/MACOSX_IDE/Xcode3 How to get the source code from CVS: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Latest Xcode can be downloaded from Apple: http://developer.apple.com/technology/xcode.html -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 05:07:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 14:07:05 +0300 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: Nathaniel, I agree with Michael that your issue is probably with incorrect hardware flow control (RTS/CTS + possibly DTR/DSR). With RXTX you can do things manually, automatically or by mixing both ways. RXTX is "low-level" enough to let developer make those decisions. Which is proper. Automatic hardware flow-control: If you want to do automatic RTS/CTS flow control in both directions (from and to PC) you must set: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Note that you must combine flow control flags with bitwise OR ( ' | ' ) Manual: If you want to bypass all flow controls signals, or handle them manually you must set: setFlowControlMode( SerialPort.FLOWCONTROL_NONE ); In manual mode, you must manually handle controlling signals from PC and reading flow control signals from by the device: RTS - Request To Send -- setRTS() method can used to set this CTS - Clear To Send -- isCTS() method can be used to read this For example, it is entirely possible to manually implement normal RTS/ CTS flow control with RXTX without relying on low-level automatic implementation. Mixed: You can also configure serial port to handle RTS/CTS automatically in only one direction, then you must set one of: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN ); or setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_OUT ); Then you can either ignore or implement manually the flow control scheme in the other direction. DTR and DSR: These are not officially flow control signals, but might affect external devices (disable, standby etc.). Use and meaning of these depends on the device. DTR - Data Terminal Ready -- setDTR() method DSR - Data Set Ready -- setDSR() method CTS/RTS standards: Please note that there are two standard ways RTS/CTS flow control is done (depends on the device): asymmetric (RS-232) symmetric (RS-232-E / TIA-232-E) For more info see: http://en.wikipedia.org/wiki/RS232#RTS.2FCTS_handshaking Some devices may even use RTS/CTS to some other non-standard purpose. With those devices, enabling automatic RTS/CTS could cause very strange behaviour as they clearly require manual control of CTS/RTS. ---- As far as I know, RXTX properly controls all these signals all the way to actual RS232 pins - unless there is a new platform incompatibility bug that I'm not aware of;) Mostly it's just wrong combination and/or usage of these additional signals that cause problems receiving or sending. And the only solution is to really *know* how your device wants these signals handled - and then code your RXTX application accordingly. Creating non-standard cable is not the right solution in my opinion. Unfortunately some applications (like HyperTerminal for example) might hit more or less accidentally to the right combination of RTS/CTS/DTR/ DSR usage and make RXTX look bad in comparison. While all RXTX does by default is - well - nothing. It gives full control the developer. -- I > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port >> Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I >> found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't >> look wrong >> to me. Am I looking at the right function or is the problem >> somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > > >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store >>> tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since >>> the old >>> cables aren't around anymore. The hardware's manual says nothing >>> except to >>> use a "Straight cable" but I figured that if it worked in >>> HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that >>> communicates with >>> the device (but doesn't do what I want, which is why I'm rolling >>> my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's >>> RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but >>> only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> > >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect >>>> to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your >>>> device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>>> (Sorry if this is a double post, but I sent my original message >>>>> without >>>>> subscribing, and since this is an urgent problem, I thought I'd >>>>> resend >>>>> after >>>>> subscribing to bypass the moderator limbo zone) >>>>> >>>>> Hi all, >>>>> >>>>> I've asked my question on StackOverflow already, so rather than >>>>> copy-paste >>>>> the question here, I'd like to redirect you there. >>>>> >>>>> Short version, I am no longer able to receive anything over >>>>> RS-232 with >>>>> RXTX, but other programs work fine. I'm definitely sending things, >>>>> because >>>>> when I connect with a different program, all the responses to the >>>>> commands I >>>>> sent via RXTX arrive all at once. >>>>> >>>>> Everything was fine in the spring, so what could have happened? >>>>> Windows >>>>> update? >>>>> >>>>> -Nate >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 06:11:11 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 15:11:11 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings Message-ID: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Hi, Summary: Patch includes multiple minor code quality improvements and also fixes one possible null pointer segfault on Mac. After this patch, compilation on Mac OS X is error/warning free even with gcc -Wall setting. I'll submit more code quality patches later that focus more on linux/ win/java. Fixes: Code quality: - First level parentheses around assignment used as while-loop truth value - Some printf formats not a string literals and including no format arguments Invalid null pointer usage: - Mac: IOMasterPort was called with (int)NULL which does not always resolve to segfault safe value. Corrected to use MACH_PORT_NULL instead. Patch: The patch is against CVS head (@2009/09/09). Attached patch file is in 'cvs diff -up' format. I'll commit this patch to the CVS later this week if there are no objections. Feel free to comment. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090909.patch Type: application/octet-stream Size: 1966 bytes Desc: not available URL: From m.j.tandy at warwick.ac.uk Wed Sep 9 06:57:55 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 13:57:55 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> OK, I just ran a test with my copy of RxTx and the following program: import gnu.io.*; public class SerialTest { public static void main(String[] args) { try { CommPortIdentifier portid = CommPortIdentifier.getPortIdentifier("COM9"); SerialPort serialPort = (SerialPort)portid.open("Serial port DTR/RTS test", 1000); serialPort.setSerialPortParams(4800, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.disableReceiveTimeout(); for (int i=0 ; i<60 ; i++) { serialPort.setDTR(true); serialPort.setRTS(true); Thread.sleep(1000); serialPort.setDTR(false); serialPort.setRTS(false); Thread.sleep(1000); } } catch (Exception e) { e.printStackTrace(); System.exit(1); } System.exit(0); } } I'm using a USB-serial converter (Prolific PL-2303) and I used a multimeter to check that my DTR and RTS pins were both toggling, and they were - between +7 and -6.4 volts. In other words, on the computer I'm using at the moment, with the version of RxTx I'm using at the moment, setDTR and setRTS both seem to work fine. I don't know if it's worth it for you to perform the same test. I gather there are several different configurations for hardware flow control, (DTR/DSR handshaking as well as RTS/CTS handshaking, handshaking for half-duplex operation, and similar) so the cable that worked for me might still be worth a try. 2009/9/9 Michael Tandy : > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong >> to me. Am I looking at the right function or is the problem somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since the old >>> cables aren't around anymore. The hardware's manual says nothing except to >>> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that communicates with >>> the device (but doesn't do what I want, which is why I'm rolling my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>> > (Sorry if this is a double post, but I sent my original message without >>>> > subscribing, and since this is an urgent problem, I thought I'd resend >>>> > after >>>> > subscribing to bypass the moderator limbo zone) >>>> > >>>> > Hi all, >>>> > >>>> > I've asked my question on StackOverflow already, so rather than >>>> > copy-paste >>>> > the question here, I'd like to redirect you there. >>>> > >>>> > Short version, I am no longer able to receive anything over RS-232 with >>>> > RXTX, but other programs work fine. I'm definitely sending things, >>>> > because >>>> > when I connect with a different program, all the responses to the >>>> > commands I >>>> > sent via RXTX arrive all at once. >>>> > >>>> > Everything was fine in the spring, so what could have happened? Windows >>>> > update? >>>> > >>>> > -Nate >>>> > >>>> > _______________________________________________ >>>> > Rxtx mailing list >>>> > Rxtx at qbang.org >>>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>>> > >>>> > >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > From david at attglobal.net Wed Sep 9 09:17:27 2009 From: david at attglobal.net (David Schmidt) Date: Wed, 09 Sep 2009 11:17:27 -0400 Subject: [Rxtx] 2.2 Release plans Message-ID: <4AA7C707.5060802@attglobal.net> I'm holding off releasing an update to my project (adtpro.sourceforge.net) to support OSX Snow Leopard because I'd like to ship an "official" build of rxtx 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for toggling a port off). CVS is looking great on OSX - thanks to all who have been hard at work on that. I wish there were just one more update - Pre3? :-) My question... If I wanted to make a release in, say, a week... would it pay to wait for rxtx, or should I plan to build and ship a local build of 2.2 out of CVS myself? - David Schmidt From tjarvi at qbang.org Wed Sep 9 19:14:29 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:14:29 -0600 (MDT) Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: On Wed, 9 Sep 2009, Ilkka Myller wrote: > Hi, > > Summary: > > Patch includes multiple minor code quality improvements and also fixes one > possible null pointer segfault on Mac. > After this patch, compilation on Mac OS X is error/warning free even with gcc > -Wall setting. > I'll submit more code quality patches later that focus more on > linux/win/java. > > Fixes: > > Code quality: > - First level parentheses around assignment used as while-loop truth value > - Some printf formats not a string literals and including no format arguments > > Invalid null pointer usage: > - Mac: IOMasterPort was called with (int)NULL which does not always resolve > to segfault safe value. Corrected to use MACH_PORT_NULL instead. > > Patch: > > The patch is against CVS head (@2009/09/09). > Attached patch file is in 'cvs diff -up' format. > > I'll commit this patch to the CVS later this week if there are no objections. > Feel free to comment. > These ifdefs can go. If you like I can remove them when you are done. #ifdef DEBUG_MW mexErrMsgTxt( msg ); #else They are just printf like debug messages for use in an environment in which I could not get directly to stderr/stdout. I don't think anyone uses them anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Sep 9 19:17:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:17:43 -0600 (MDT) Subject: [Rxtx] 2.2 Release plans In-Reply-To: <4AA7C707.5060802@attglobal.net> References: <4AA7C707.5060802@attglobal.net> Message-ID: On Wed, 9 Sep 2009, David Schmidt wrote: > I'm holding off releasing an update to my project (adtpro.sourceforge.net) to > support OSX Snow Leopard because I'd like to ship an "official" build of rxtx > 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for > toggling a port off). CVS is looking great on OSX - thanks to all who have > been hard at work on that. I wish there were just one more update - Pre3? > :-) > > My question... If I wanted to make a release in, say, a week... would it pay > to wait for rxtx, or should I plan to build and ship a local build of 2.2 out > of CVS myself? > Hi David, I would suggest planning on shipping a local build in a 1 week timeframe. We could put another prerelease up but there are still fixes coming in. -- Trent Jarvi tjarvi at qbang.org From ilkka at myller.com Wed Sep 9 23:07:34 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:07:34 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: <04A41559-598C-4B6E-821A-DA90CB6228E7@myller.com> Patch (im-20090909.patch) has been committed to the CVS. Trent: I'll include DEBUG_MW cleanup to my next patch. > > On Wed, 9 Sep 2009, Ilkka Myller wrote: > >> Hi, >> >> Summary: >> >> Patch includes multiple minor code quality improvements and also >> fixes one possible null pointer segfault on Mac. >> After this patch, compilation on Mac OS X is error/warning free >> even with gcc -Wall setting. >> I'll submit more code quality patches later that focus more on >> linux/win/java. >> >> Fixes: >> >> Code quality: >> - First level parentheses around assignment used as while-loop >> truth value >> - Some printf formats not a string literals and including no format >> arguments >> >> Invalid null pointer usage: >> - Mac: IOMasterPort was called with (int)NULL which does not always >> resolve to segfault safe value. Corrected to use MACH_PORT_NULL >> instead. >> >> Patch: >> >> The patch is against CVS head (@2009/09/09). >> Attached patch file is in 'cvs diff -up' format. >> >> I'll commit this patch to the CVS later this week if there are no >> objections. >> Feel free to comment. >> > > These ifdefs can go. If you like I can remove them when you are done. > > #ifdef DEBUG_MW > mexErrMsgTxt( msg ); > #else > > They are just printf like debug messages for use in an environment > in which I could not get directly to stderr/stdout. I don't think > anyone uses them anymore. > > -- > Trent Jarvi > tjarvi at qbang.org From ilkka at myller.com Wed Sep 9 23:35:13 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:35:13 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= Message-ID: Hi, Summary: Patch fixes compiling on Linux distributions/kernels that dont ship with linux/utsrelease.h header and therefore have no UTS_RELEASE defined. Usually this applies only to newer distributions and/or kernels - for example Ubuntu 9.04. Fixes: The UTS_RELEASE vs uname checking in initialization functions is now done only in debug build and only when UTS_RELEASE is actually defined. Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910.patch Type: application/octet-stream Size: 9542 bytes Desc: not available URL: From ilkka at myller.com Thu Sep 10 06:43:02 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 15:43:02 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= In-Reply-To: References: Message-ID: Patch has been committed to CVS. > Hi, > > Summary: > > Patch fixes compiling on Linux distributions/kernels that dont ship > with linux/utsrelease.h header and therefore have no UTS_RELEASE > defined. > Usually this applies only to newer distributions and/or kernels - > for example Ubuntu 9.04. > > Fixes: > > The UTS_RELEASE vs uname checking in initialization functions is now > done only in debug build and only when UTS_RELEASE is actually > defined. > > Patch: > > The patch is against CVS head (@2009/09/10). > Attached patch file is in 'cvs diff -up' format. > > > Thanks, > > -- > I > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Thu Sep 10 09:08:01 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 18:08:01 +0300 Subject: [Rxtx] [Patch] Remove unused MathWorks MATLAB DEBUG_MW ifdefs Message-ID: <6DB57DB1-A47E-4435-9CD6-212B671A2849@myller.com> Summary: Patch removes unused MathWorks MATLAB timing debug ifdefs (DEBUG_MW). This is a request from Trent. Fixes: - Removes DEBUG_MW definitions - Removes unused mex....() function definitions - Corrects DEBUG_TIMING to work properly without mexPrintf (with Mac OS X specific format string fixes included) - Removes unused/duplicate timeval struct and DEBUG_TIMING definitions from SerialImp.c and SerialImp.h - Corrects fprintf call in SerialImp.cpp Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910b.patch Type: application/octet-stream Size: 9841 bytes Desc: not available URL: From Kapil_Gupta at hcl.in Thu Sep 10 10:25:29 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 10 Sep 2009 21:55:29 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, I am getting some problem with RXTX on macintosh (reading some data from the device attached to the usb port through usb to serial mechanism). I used the RXTX 2.1.7 then I got PortInUseException but after using 2.2pre it worked fine. But it works only for the first time, it hangs in the second time while opening the port. Please find the attached code. This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Thu Sep 10 13:00:14 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 22:00:14 +0300 Subject: [Rxtx] [Patch] Implement return value checking to file I/O calls Message-ID: Summary: The return value of some functions should always be used. For example, it is dangerous to not check the return value of a write(), read(), open(), fscanf() calls. This patch fixes such occurences in RXTX code. For example: unchecked read() call could result in later - and often seemingly unrelated - segfault due to undefined read buffer contents. After this patch the Linux build process is error/warning free even with gcc -Wall -Werror. Fixes: - Implemented return value checking to file I/O calls in SerialImp.c:fhs_lock(), uucp_lock() and is_device_locked() functions. - Added error recovery for fuserImp.c fscanf() calls. Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910c.patch Type: application/octet-stream Size: 3370 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Thu Sep 10 13:08:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 22:08:05 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> Hi Kapil, I believe this issue has been fixed in CVS version, but still exists in 2.2pre2 available from RXTX wiki. For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html As you've seen from the recent patches announced on this list, we are working very hard to make a new 2.2pre(?) release available. Meanwhile, you can compile your own RXTX binaries from CVS source. On Mac it should be exceptionally easy with new Xcode 3.x project files. Thank you for your patience, -- I > > I am getting some problem with RXTX on macintosh (reading some data > from the device attached to the usb port through usb to serial > mechanism). I used the RXTX 2.1.7 then I got PortInUseException but > after using 2.2pre it worked fine. But it works only for the first > time, it hangs in the second time while opening the port. From ilkka at myller.com Fri Sep 11 04:07:22 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 13:07:22 +0300 Subject: [Rxtx] [Patch] Windows build improvements (MinGW32, MSVC and LCC) Message-ID: <81D06766-8D51-485A-B2A2-624C8EA690BA@myller.com> Summary: Fixes various compiler warnings with Windows builds. Removes unused code blocks from compilation. After this patch the Windows build process is error/warning free with MinGW32, MSVC and LCC compilers - even with -Wall enabled. Does not fix: Latest LCC compiler version still fails even after this patch due to compiler trap error. Trap error does not specify source code location - it fails outputting SerialImp.obj binary. Compiling SerialImp.c without binary output works. Could this be a bug in LCC? Tested with clean RXTX source, latest standard LCC installation and with both Windows Vista SP1 x86 and Windows XP SP3 x86. Patch: The patch is against CVS (@2009/09/11). Attached patch file is in 'cvs diff -up' format. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090911.patch Type: application/octet-stream Size: 6673 bytes Desc: not available URL: From Kapil_Gupta at hcl.in Fri Sep 11 08:21:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Fri, 11 Sep 2009 19:51:24 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Ilkka, I tried getting the source code from the CVS but we could not able to do so, the CVS was not responding. Then we downloaded the 2.2 pre2 code and made the changes that are described in http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html but the problem didn't change. First time the device responds well and the second time it hangs. Did you see the code that we have sent to you, so that you can suggest if we are doing something wrong in our code. Again attaching if you have deleted that. Please suggest (does the CVS code can help rather using the patch provided by you?). Thanks, Kapil -----Original Message----- From: Ilkka Myller [mailto:ilkka at myller.com] Sent: Friday, September 11, 2009 12:38 AM To: Kapil Gupta Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Hi Kapil, I believe this issue has been fixed in CVS version, but still exists in 2.2pre2 available from RXTX wiki. For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html As you've seen from the recent patches announced on this list, we are working very hard to make a new 2.2pre(?) release available. Meanwhile, you can compile your own RXTX binaries from CVS source. On Mac it should be exceptionally easy with new Xcode 3.x project files. Thank you for your patience, -- I > > I am getting some problem with RXTX on macintosh (reading some data > from the device attached to the usb port through usb to serial > mechanism). I used the RXTX 2.1.7 then I got PortInUseException but > after using 2.2pre it worked fine. But it works only for the first > time, it hangs in the second time while opening the port. DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Fri Sep 11 09:33:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 18:33:33 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Hi Kapil, For CVS: Instructions at the old rxtx website are incorrect. Trent updated them, but to a wrong server address "qgang.org" -- the correct server is "qbang.org". Please follow instructions from rxtx wiki: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code About testing your code: When I have time (maybe this weekend), I'll test your code using Mac OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. What USB serial port you are using with your Mac? Something with FTDI chip? or maybe Prolific? What adapter driver version you are using? Just asking, so I can test with the same configuration. Meanwhile I suggest you: - Make sure you have the latest USB Serial adapter drivers, so we can eliminate past issues with those. - Check that you are not having multiple copies of librxtxSerial.jnilib (possibly different versions) in your java library path (=trouble;) - Check for any USB Serial adaptors kernel extension error messages in system log after testing your software (use Console.app to browse logs) -- I Kapil Gupta kirjoitti 11.9.2009 kello 17.21: > Hi Ilkka, > > I tried getting the source code from the CVS but we could not able > to do so, the CVS was not responding. Then we downloaded the 2.2 > pre2 code and made the changes that are described in http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html > but the problem didn't change. First time the device responds well > and the second time it hangs. > > Did you see the code that we have sent to you, so that you can > suggest if we are doing something wrong in our code. Again attaching > if you have deleted that. Please suggest (does the CVS code can help > rather using the patch provided by you?). > > Thanks, > Kapil > > -----Original Message----- > From: Ilkka Myller [mailto:ilkka at myller.com] > Sent: Friday, September 11, 2009 12:38 AM > To: Kapil Gupta > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second > time port open > > Hi Kapil, > > I believe this issue has been fixed in CVS version, but still exists > in 2.2pre2 available from RXTX wiki. > > For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html > > As you've seen from the recent patches announced on this list, we are > working very hard to make a new 2.2pre(?) release available. > > Meanwhile, you can compile your own RXTX binaries from CVS source. On > Mac it should be exceptionally easy with new Xcode 3.x project files. > > > Thank you for your patience, > > > -- > I > > >> >> I am getting some problem with RXTX on macintosh (reading some data >> from the device attached to the usb port through usb to serial >> mechanism). I used the RXTX 2.1.7 then I got PortInUseException but >> after using 2.2pre it worked fine. But it works only for the first >> time, it hangs in the second time while opening the port. > > > DISCLAIMER: > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential > and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of this > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > ----------------------------------------------------------------------------------------------------------------------- > From ilkka at myller.com Fri Sep 11 11:51:13 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 20:51:13 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Message-ID: <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> Ok, I debugged your code on Mac using USB-RS232 adapter + loopback adapter. My findings: there are no issues with RXTX in your code -- there are issues with threading and synchronization. Primary issue: you essentially lock the JVM main thread to 100% CPU usage with infinite loop: while (!processCompleted) { ; } Now.. I'm going to give you a bad advice, mostly because you have bigger threading issues there.. but we must continue somehow: A quick remedy to previous is: while (!processCompleted) { Thread.yield(); } Thread yielding gives other threads atleast a chance to run (and to processCompleted boolean to actually update in main thread context). What happens next is that your main-thread is allowed to continue and proceeds to closeConnection() call it otherwise would never reach. After that, connection closes properly.. main() method continues to "System.out.println(result);" and proceeds to exit JVM.. .. except.. Secondary issue: Exit is one thing JVM cant do since you have left a Timer thread hanging without proper closing in getData() method. Cancel it (uncomment that line) - and your code completes main() to a clean JVM exit. So, my advice to you is to focus on fixing threading, timers and synchronization. Design those well and everything works. Multithreading, done well or not, will not usually confuse RXTX ... but your own code might not be so lucky. -- I > > When I have time (maybe this weekend), I'll test your code using Mac > OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. >> >> Did you see the code that we have sent to you, so that you can >> suggest if we are doing something wrong in our code. Again >> attaching if you have deleted that. Please suggest (does the CVS >> code can help rather using the patch provided by you?). -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 11 15:19:26 2009 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 11 Sep 2009 17:19:26 -0400 Subject: [Rxtx] Can't run my Netbeans/Java s/w on a MAC Message-ID: <4AAABEDE.7020508@howardz.com> An HTML attachment was scrubbed... URL: From ilkka at myller.com Fri Sep 11 15:41:10 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 12 Sep 2009 00:41:10 +0300 Subject: [Rxtx] Can't run my Netbeans/Java s/w on a MAC In-Reply-To: <4AAABEDE.7020508@howardz.com> References: <4AAABEDE.7020508@howardz.com> Message-ID: <35D4BD73-B8CC-4DEE-A846-8858C9C9EBC7@myller.com> Hi, The bug that causes the segfault (invalid memory access) has been fixed (in CVS): http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html Next prerelease is coming (soon I hope), but the the 2.2pre2 fails when reopening the serial port on Mac OS X. -- I > > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] Jar > version = RXTX-2.2pre1 > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] native > lib Version = RXTX-2.2pre2 > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] Invalid > memory access of location 0x12b5e3938 rip=0x12955012f > 9/6/09 3:46:00 PM ReportCrash[6164] Saved crash report for java > [6162] version 13.0.0 (13.0.0) to /Users/myles/Library/Logs/ > DiagnosticReports/java_2009-09-06-154600_myles-PowerBook-PP-108.crash -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Fri Sep 11 20:15:31 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 11 Sep 2009 20:15:31 -0600 (MDT) Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Message-ID: On Fri, 11 Sep 2009, Ilkka Myller wrote: > Hi Kapil, > > For CVS: > > Instructions at the old rxtx website are incorrect. Trent updated them, but > to a wrong server address "qgang.org" -- the correct server is "qbang.org". > Please follow instructions from rxtx wiki: > > http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code The old website has been corrected. -- Trent Jarvi tjarvi at qbang.org From dvd at newfoundmarket.com Sat Sep 12 11:49:48 2009 From: dvd at newfoundmarket.com (DVD) Date: Sat, 12 Sep 2009 13:49:48 -0400 Subject: [Rxtx] RXTX on linux hang Message-ID: <4AABDF3C.2040908@newfoundmarket.com> Hello: I just did a fresh install of RXTZ on both Ubuntu and centos, Java version 6, update 12 I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with the Usage example from your website Two way communcation with the serial port I used the computer's serial port /dev/ttyS0, with UART 16550A the program simply hang. The port was opened and both input/output streamed were opened but the writing/reading are not working. Any help would be appreciated. I tried this program on windows and it worked fine. Thanks From ilkka at myller.com Sat Sep 12 15:31:26 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sun, 13 Sep 2009 00:31:26 +0300 Subject: [Rxtx] RXTX on linux hang In-Reply-To: <4AABDF3C.2040908@newfoundmarket.com> References: <4AABDF3C.2040908@newfoundmarket.com> Message-ID: Hi, It's very hard to say what could be wrong without more details. Can you tell me more about your Linux setup: - Output of: uname -a - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your test code running) - Output of: cat /proc/tty/driver/serial - Are you you testing with root privileges - What kind of device you are communicating with (or just a loopback dongle)? - Does your device expect some specific flow control and/or specific state of DTR/DSR signals? - Have you tried configuring those flow controls and other RS232 signals in your test code? Did they work? - Do other simple terminal programs work (easiest to try: screen /dev/ ttyS0 )? - What is the CPU usage (use 'top' or some other process monitor your like) of your test software when it "hangs"? I can try to duplicate your issue on Ubuntu 9.04 (both x86 and x86_64), Centos 5 (x86) and Debian 5.0 (x86). I'd prefer to test with the same kind of system you have.. Thanks, -- I > > I just did a fresh install of RXTZ on both Ubuntu and centos, Java > version 6, update 12 > I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with > the Usage example from > your website > > Two way communcation with the serial port > > > I used the computer's serial port /dev/ttyS0, with UART 16550A > > the program simply hang. The port was opened and both input/output > streamed were opened > but the writing/reading are not working. > > Any help would be appreciated. I tried this program on windows and > it worked fine. From dvd at newfoundmarket.com Sat Sep 12 21:20:14 2009 From: dvd at newfoundmarket.com (DVD) Date: Sat, 12 Sep 2009 23:20:14 -0400 Subject: [Rxtx] RXTX on linux hang In-Reply-To: References: <4AABDF3C.2040908@newfoundmarket.com> Message-ID: <4AAC64EE.7050904@newfoundmarket.com> Thank you very much for the steps. It is pin out problem. Again, Thanks. Ilkka Myller wrote: > Hi, > > It's very hard to say what could be wrong without more details. > Can you tell me more about your Linux setup: > > - Output of: uname -a > - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your > test code running) > - Output of: cat /proc/tty/driver/serial > - Are you you testing with root privileges > - What kind of device you are communicating with (or just a loopback > dongle)? > - Does your device expect some specific flow control and/or specific > state of DTR/DSR signals? > - Have you tried configuring those flow controls and other RS232 > signals in your test code? Did they work? > - Do other simple terminal programs work (easiest to try: screen > /dev/ttyS0 )? > - What is the CPU usage (use 'top' or some other process monitor your > like) of your test software when it "hangs"? > > > I can try to duplicate your issue on Ubuntu 9.04 (both x86 and > x86_64), Centos 5 (x86) and Debian 5.0 (x86). > I'd prefer to test with the same kind of system you have.. > > > Thanks, > > -- > I > > >> >> I just did a fresh install of RXTZ on both Ubuntu and centos, Java >> version 6, update 12 >> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with >> the Usage example from >> your website >> >> Two way communcation with the serial port >> >> >> >> I used the computer's serial port /dev/ttyS0, with UART 16550A >> >> the program simply hang. The port was opened and both input/output >> streamed were opened >> but the writing/reading are not working. >> >> Any help would be appreciated. I tried this program on windows and >> it worked fine. > From tjarvi at qbang.org Sun Sep 13 14:06:33 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Sep 2009 12:06:33 -0600 (MDT) Subject: [Rxtx] RXTX on linux hang In-Reply-To: <4AAC64EE.7050904@newfoundmarket.com> References: <4AABDF3C.2040908@newfoundmarket.com> <4AAC64EE.7050904@newfoundmarket.com> Message-ID: Hi, Would it be possible to get a short paragraph from you describing the pinout problem and how you discovered it? We can add that to the wiki to help others get past the problem faster next time. On Sat, 12 Sep 2009, DVD wrote: > Thank you very much for the steps. It is pin out problem. > Again, Thanks. > > Ilkka Myller wrote: >> Hi, >> >> It's very hard to say what could be wrong without more details. >> Can you tell me more about your Linux setup: >> >> - Output of: uname -a >> - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your test >> code running) >> - Output of: cat /proc/tty/driver/serial >> - Are you you testing with root privileges >> - What kind of device you are communicating with (or just a loopback >> dongle)? >> - Does your device expect some specific flow control and/or specific state >> of DTR/DSR signals? >> - Have you tried configuring those flow controls and other RS232 signals in >> your test code? Did they work? >> - Do other simple terminal programs work (easiest to try: screen /dev/ttyS0 >> )? >> - What is the CPU usage (use 'top' or some other process monitor your like) >> of your test software when it "hangs"? >> >> >> I can try to duplicate your issue on Ubuntu 9.04 (both x86 and x86_64), >> Centos 5 (x86) and Debian 5.0 (x86). >> I'd prefer to test with the same kind of system you have.. >> >> >> Thanks, >> >> -- >> I >> >> >>> >>> I just did a fresh install of RXTZ on both Ubuntu and centos, Java version >>> 6, update 12 >>> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with the >>> Usage example from >>> your website >>> >>> Two way communcation with the serial port >>> >>> >>> I used the computer's serial port /dev/ttyS0, with UART 16550A >>> >>> the program simply hang. The port was opened and both input/output >>> streamed were opened >>> but the writing/reading are not working. >>> >>> Any help would be appreciated. I tried this program on windows and it >>> worked fine. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dvd at newfoundmarket.com Sun Sep 13 21:18:08 2009 From: dvd at newfoundmarket.com (DVD) Date: Sun, 13 Sep 2009 21:18:08 -0400 Subject: [Rxtx] RXTX on linux hang In-Reply-To: References: <4AABDF3C.2040908@newfoundmarket.com> <4AAC64EE.7050904@newfoundmarket.com> Message-ID: <4AAD99D0.3030206@newfoundmarket.com> Hello, It was a human mistake during wiring and was discovered after staring at it for a while :-). Nothing technical worth mentioning. Thanks Trent Jarvi wrote: > > Hi, > > Would it be possible to get a short paragraph from you describing the > pinout problem and how you discovered it? We can add that to the wiki > to help others get past the problem faster next time. > > On Sat, 12 Sep 2009, DVD wrote: > >> Thank you very much for the steps. It is pin out problem. >> Again, Thanks. >> >> Ilkka Myller wrote: >>> Hi, >>> >>> It's very hard to say what could be wrong without more details. >>> Can you tell me more about your Linux setup: >>> >>> - Output of: uname -a >>> - Output of: stty -a -F /dev/ttyS0 (if possible: with and without >>> your test code running) >>> - Output of: cat /proc/tty/driver/serial >>> - Are you you testing with root privileges >>> - What kind of device you are communicating with (or just a loopback >>> dongle)? >>> - Does your device expect some specific flow control and/or specific >>> state of DTR/DSR signals? >>> - Have you tried configuring those flow controls and other RS232 >>> signals in your test code? Did they work? >>> - Do other simple terminal programs work (easiest to try: screen >>> /dev/ttyS0 )? >>> - What is the CPU usage (use 'top' or some other process monitor >>> your like) of your test software when it "hangs"? >>> >>> >>> I can try to duplicate your issue on Ubuntu 9.04 (both x86 and >>> x86_64), Centos 5 (x86) and Debian 5.0 (x86). >>> I'd prefer to test with the same kind of system you have.. >>> >>> >>> Thanks, >>> >>> -- >>> I >>> >>> >>>> >>>> I just did a fresh install of RXTZ on both Ubuntu and centos, Java >>>> version 6, update 12 >>>> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with >>>> the Usage example from >>>> your website >>>> >>>> Two way communcation with the serial port >>>> >>>> >>>> I used the computer's serial port /dev/ttyS0, with UART 16550A >>>> >>>> the program simply hang. The port was opened and both input/output >>>> streamed were opened >>>> but the writing/reading are not working. >>>> >>>> Any help would be appreciated. I tried this program on windows and >>>> it worked fine. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From tjarvi at qbang.org Tue Sep 1 02:38:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 1 Sep 2009 02:38:40 -0600 (MDT) Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks Ilkka The problem should be resolved (confirmed from two locations). I'll be trying to hunt down a Snow Leopard box tomorrow evening as well. On Tue, 1 Sep 2009, Ilkka Myller wrote: > Hi, > > CVS server is reachable, but when trying anonymous login it replies: > > " > Fatal error, aborting. > anonymous: no such system user > " > > It seems that the anonymous cvs account is not yet properly configured on the > new system. > > -- > I > >> On Mon, 31 Aug 2009, Trent Jarvi wrote: >> >> The server has been beemed to another location for those experiencing >> routing problems. >> >> in bash: >> >> export CVSROOT=:pserver:anonymous at qbang.org:2401/var/cvs/cvsroot >> cvs login (no passwd) >> cvs co -r commapi-0-0-1 rxtx-devel >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Tue Sep 1 03:05:59 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 12:05:59 +0300 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks, The new CVS server works well :) I can also confirm that latest CVS version builds properly with unmodified Snow Leopard (Mac OS X 10.6) system: Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 gcc version 4.2.1 (Apple Inc. build 5646) Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) --> Resulting JNI library (Universal Binary): i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = 9d15fc488b301da8bf65b2c9456a7bbb --> Resulting JAR: RXTXComm.jar / 60942 bytes MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 Atleast it builds.. and probably works too. I have not tested that yet. -- I Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > The problem should be resolved (confirmed from two locations). I'll > be trying to hunt down a Snow Leopard box tomorrow evening as well. From jimmy.lee at emotum.com Tue Sep 1 05:07:19 2009 From: jimmy.lee at emotum.com (Jimmy Lee [emotum]) Date: Tue, 1 Sep 2009 21:07:19 +1000 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: <112685a90909010407i6054acb5tc2b12196797bfaf1@mail.gmail.com> Could we access to the binaries? Please :) 2009/9/1 Ilkka Myller > Thanks, > > The new CVS server works well :) > > I can also confirm that latest CVS version builds properly with unmodified > Snow Leopard (Mac OS X 10.6) system: > > Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_I386 i386 > gcc version 4.2.1 (Apple Inc. build 5646) > Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) > > > --> Resulting JNI library (Universal Binary): > > i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes > > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 > librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc > > MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = > 9d15fc488b301da8bf65b2c9456a7bbb > > > --> Resulting JAR: > > RXTXComm.jar / 60942 bytes > > MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 > > > > Atleast it builds.. and probably works too. I have not tested that yet. > > -- > I > > Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > > The problem should be resolved (confirmed from two locations). I'll be >> trying to hunt down a Snow Leopard box tomorrow evening as well. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Tue Sep 1 06:21:28 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Tue, 1 Sep 2009 08:21:28 -0400 (EDT) Subject: [Rxtx] Snow Leopard binaries Message-ID: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> +1 for binaries - pretty please with sugar on top... -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com From fredm at alum.mit.edu Tue Sep 1 06:24:17 2009 From: fredm at alum.mit.edu (Fred G. Martin) Date: Tue, 1 Sep 2009 08:24:17 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> Message-ID: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> You can find one here: http://iharder.sourceforge.net/current/java/ Also, you need to add yourself (any rxtx user) to the uucp group. Niutils don't exist, but dscl is a replacement. There is info for using it here: http://aplawrence.com/MacOSX/directory_services.html Fred On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Tue Sep 1 07:03:37 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Tue, 1 Sep 2009 18:33:37 +0530 Subject: [Rxtx] Help for RXTX on mac Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time I am able to read the device but on second time, it hangs on COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then it was showing the PortInUseException, I replaced the RXTX library to 2.2Pre1 so it is showing this problem. Is this is a problem with RXTX on Mac? Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: From ilkka at myller.com Tue Sep 1 07:57:06 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 16:57:06 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:02:31 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:02:31 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:43:49 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:43:49 +0300 Subject: [Rxtx] Help for RXTX on mac In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE@myller.com> Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Arseneau at Sun.COM Tue Sep 1 08:51:32 2009 From: Eric.Arseneau at Sun.COM (Eric Arseneau) Date: Tue, 01 Sep 2009 07:51:32 -0700 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24@sun.com> Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 09:24:30 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 18:24:30 +0300 Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D@myller.com> Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Thu Sep 3 02:50:16 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Thu, 3 Sep 2009 10:50:16 +0200 Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s From Kapil_Gupta at hcl.in Thu Sep 3 06:52:21 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:22:21 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From Kapil_Gupta at hcl.in Thu Sep 3 07:15:19 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:45:19 +0530 Subject: [Rxtx] Rxtx Digest, Vol 25, Issue 3 In-Reply-To: References: Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C50BB@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi myller, I have attached the code with the mail. Please help me if I am doing something wrong in it. Thanks & Regards, Kapil Gupta -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of rxtx-request at qbang.org Sent: Thursday, September 03, 2009 4:15 PM To: rxtx at qbang.org Subject: Rxtx Digest, Vol 25, Issue 3 Send Rxtx mailing list submissions to rxtx at qbang.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qbang.org/mailman/listinfo/rxtx or, via email, send a message with subject or body 'help' to rxtx-request at qbang.org You can reach the person managing the list at rxtx-owner at qbang.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Rxtx digest..." Today's Topics: 1. Re: Snow Leopard binaries (Ilkka Myller) 2. Re: Snow Leopard binaries (Ilkka Myller) 3. Re: Help for RXTX on mac (Ilkka Myller) 4. Re: Snow Leopard binaries (Eric Arseneau) 5. Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters (Ilkka Myller) 6. RXTX multiple crashes (Kjetil ?ster?s) 7. RXTX 2.2Pre + MacMini+ Deadlock while second time port open (Kapil Gupta) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Sep 2009 16:57:06 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 1 Sep 2009 17:02:31 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <55EC133D-DC83-45A3-849C-02714904D580 at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 1 Sep 2009 17:43:49 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Help for RXTX on mac Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Tue, 01 Sep 2009 07:51:32 -0700 From: Eric Arseneau Cc: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24 at sun.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 1 Sep 2009 18:24:30 +0300 From: Ilkka Myller To: rxtx Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Thu, 3 Sep 2009 10:50:16 +0200 From: Kjetil ?ster?s To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s ------------------------------ Message: 7 Date: Thu, 3 Sep 2009 18:22:21 +0530 From: Kapil Gupta To: "rxtx at qbang.org" Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059 at NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset="us-ascii" Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: ------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx End of Rxtx Digest, Vol 25, Issue 3 *********************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From ilkka at myller.com Thu Sep 3 11:17:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 3 Sep 2009 20:17:27 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <4520677F-E8F0-46F5-B4AD-3AD3A7C2AED3@myller.com> Hi Kapil, The code is incomplete and I did not find anything I could to test/ debug with this. I also tried to find the actual serial port opening, but found only a call to missing method which creates the SerialPort object (?): serialPort = getSerialPortConnection( COMPort, this.readEvent.getDeviceName(), SerialCommConfig.DEVICE1[SerialCommConfig.TIMEOUT], SerialCommConfig.DEVICE1[SerialCommConfig.BAUDRATE], SerialCommConfig.DEVICE1[SerialCommConfig.DATABITS], SerialCommConfig.DEVICE1[SerialCommConfig.STOPBITS], SerialCommConfig.DEVICE1[SerialCommConfig.PARITY] ); The class SerialCommConfig is missing too. If this is a part of the actual code you are using, please note that you are not actually closing the serial port. The call to close() method is commented out: try { // serialPort.close(); } catch (Exception ex) { ex.printStackTrace(); } Re-opening of the serial port wont work if you haven't properly closed it first. -- I > > I am using RXTX on Macintosh to communicate to my device. First time > the device responds well but on second time, it hangs on > COMPort.open (name, timeout). > > I have attached the source code in a file. Please help me. > > Thanks & Best Regards, > Kapil -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorton at intellimec.com Thu Sep 3 11:37:55 2009 From: dmorton at intellimec.com (Daniel Morton) Date: Thu, 3 Sep 2009 13:37:55 -0400 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. (I haven't tried previous version though). Daniel Morton Java/J2EE Developer Tel +1 519.745.8887 x4331 Email dmorton at intellimec.com www.intellimec.com | www.iLane.com | www.drivesync.com Intelligent Mechatronic Systems Inc. 435 King Street North Waterloo, ON N2J 2Z5 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s Sent: Thursday, September 03, 2009 4:50 AM To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. From alexanderkiel at gmx.net Fri Sep 4 02:29:15 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 10:29:15 +0200 Subject: [Rxtx] Official Javadoc Location Message-ID: <1252052955.4025.80.camel@T61-KIEL> Hi List, I wasn't able to find an official location of RXTX Javadoc accessible over HTTP. Maybe someone can link me to it. If there is no such location, I would like to see one. I like to link from my own Javadoc to such a location. Thanks Alexander - e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:19:25 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:19:25 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> Message-ID: <1252055965.4025.84.camel@T61-KIEL> Hi Michael, thanks for the pointer. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 09:48 +0100, Michael Tandy wrote: > RxTx javadoc: http://users.frii.com/jarvi/rxtx/doc/index.html > Javax interface RxTx duplicates javadoc: > http://java.sun.com/products/javacomm/reference/api/index.html > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:22:14 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:22:14 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> Message-ID: <1252056134.4025.87.camel@T61-KIEL> Hi Eike, thanks, but I need a direct package pointer so that Javadoc will link the gnu.io packages automatically to the right location. Michael has pointed me to http://users.frii.com/jarvi/rxtx/doc/index.html which has the gnu.io packages. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 11:04 +0200, Eike Hinderk J?rrens wrote: > Hi Alexander, > it seems to me that RXTX is implementing this API: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Kind regards, > Eike > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kjetilos at gmail.com Fri Sep 4 03:43:41 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 11:43:41 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> Message-ID: <7a803d460909040243ke4449ecucbe2cd8b15761746@mail.gmail.com> Hi Daniel, This is interesting, what type of application are you making? Is there a lot of signaling on different COM ports at the same time in your application? In our application we have 11 devices connected to different COM ports, 9 of these are in active use when the application is running. I'm wondering how to use the RXTX library version 2.1.7 in this scenario without causing it to crash. After adding more signaling on the COM ports in our application we have now experienced other crashes and it is natural to think that it has something to do with our way of using RXTX from several threads at the same time. So my question is are there any methods like read/write/flush/close that are not thread safe and should be handled with care? And similarly is the RXTXPort.SerialInputStream and RXTXPort.SerialOutputStream thread safe? 2009/9/3 Daniel Morton : > I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. ?(I haven't tried previous version though). > > Daniel Morton > Java/J2EE Developer > > Tel ? ?+1 519.745.8887 x4331 > Email ? ?dmorton at intellimec.com > > > www.intellimec.com ?| ?www.iLane.com ?| ?www.drivesync.com > > > > Intelligent Mechatronic Systems Inc. > 435 King Street North Waterloo, ON N2J 2Z5 > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s > Sent: Thursday, September 03, 2009 4:50 AM > To: rxtx at qbang.org > Subject: [Rxtx] RXTX multiple crashes > > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x7d0d] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0ce75800): ?JavaThread "Y Worker" daemon > [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 > > Registers: > EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 > ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 > EIP=0x10007d0d, EFLAGS=0x00010202 > > Top of Stack: (sp=0x0d7ff6d8) > 0x0d7ff6d8: ? 0d7ff700 00000000 00000000 00000000 > 0x0d7ff6e8: ? 02a2eae8 00000123 00002958 0d7ff718 > 0x0d7ff6f8: ? 7c830887 7c90d28a 7c8664b5 00000e2c > 0x0d7ff708: ? 00002958 00000000 00000000 7c90cffa > 0x0d7ff718: ? 7c809bdb 00002958 0d7ff758 00000e40 > 0x0d7ff728: ? 00002958 02bd0468 0ce75800 080e4ee0 > 0x0d7ff738: ? 00000000 00000000 00000000 00000000 > 0x0d7ff748: ? 00000000 00000000 00000014 7c90d09a > > Instructions: (pc=0x10007d0d) > 0x10007cfd: ? 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 > 0x10007d0d: ? 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 > > > Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x7d0d] > J ?gnu.io.RXTXPort.nativeDrain(Z)Z > J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > ... > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x9c55] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0cddf400): ?JavaThread "XXX Worker" daemon > [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 > > Registers: > EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 > ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 > EIP=0x10009c55, EFLAGS=0x00010206 > > Top of Stack: (sp=0x0bb8f830) > 0x0bb8f830: ? 00000000 00000000 c0000005 00000000 > 0x0bb8f840: ? 00000000 00f1f0a5 00000002 00000000 > 0x0bb8f850: ? 003a0100 0001003f 0bb8fb20 0b9ff918 > 0x0bb8f860: ? 00000000 00000000 0bb8fb68 0bb8fb20 > 0x0bb8f870: ? 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 > 0x0bb8f880: ? 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 > 0x0bb8f890: ? 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 > 0x0bb8f8a0: ? 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 > > Instructions: (pc=0x10009c55) > 0x10009c45: ? 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff > 0x10009c55: ? 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 > > > Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x9c55] > C ?[rxtxSerial.dll+0xa05e] > J ?gnu.io.RXTXPort.readByte()I > J ?gnu.io.RXTXPort$SerialInputStream.read()I > J ?java.io.FilterInputStream.read()I > ... > > -- > Kjetil ?ster?s > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kjetil ?ster?s From tjarvi at qbang.org Fri Sep 4 06:00:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Sep 2009 06:00:40 -0600 (MDT) Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x7d0d] > J gnu.io.RXTXPort.nativeDrain(Z)Z > J gnu.io.RXTXPort$SerialOutputStream.flush()V > Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x9c55] > C [rxtxSerial.dll+0xa05e] > J gnu.io.RXTXPort.readByte()I > J gnu.io.RXTXPort$SerialInputStream.read()I RXTX 2.1-7 has concurrency issues that will show upon multicore systems. These should be resolved in the 2.2 pre release. A user application could synchronize the read/write/open/close calls while using 2.1 to avoid the concurrency issue. The flush is probably following a write while the readByte is coming from read(byte b). The bugs existed in rxtx for a long time. I assume changes in the JVM and the presence of multicore systems exposed the issues. -- Trent Jarvi tjarvi at qbang.org From kjetilos at gmail.com Fri Sep 4 06:33:33 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 14:33:33 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <7a803d460909040533n1caf240y8168477a578bc45c@mail.gmail.com> Den 4. september 2009 14.00 skrev Trent Jarvi f?lgende: > > > On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > >> Hi >> >> We are using RXTX version 2.1.7 actively and lately we are having some >> issues with the RXTX library crashing. We are running a windows xp >> system with multiple COM ports where each COM port have a serial >> device connected. Lately we have increased the amount of signaling >> done over the COM ports and we are experiencing several odd crashes. I >> tried to search the mailinglist for something similar but was unable >> to find anything. At one time the RXTX crashed in the >> gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the >> gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack >> traces if someone is interested in having a look. Has anyone seen the >> same crashes? and does anyone know what can cause such crash? >> >> >> Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x7d0d] >> J ?gnu.io.RXTXPort.nativeDrain(Z)Z >> J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > >> Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x9c55] >> C ?[rxtxSerial.dll+0xa05e] >> J ?gnu.io.RXTXPort.readByte()I >> J ?gnu.io.RXTXPort$SerialInputStream.read()I > > > RXTX 2.1-7 has concurrency issues that will show upon multicore systems. > These should be resolved in the 2.2 pre release. ?A user application could > synchronize the read/write/open/close calls while using 2.1 to avoid the > concurrency issue. > > The flush is probably following a write while the readByte is coming from > read(byte b). > > The bugs existed in rxtx for a long time. ?I assume changes in the JVM and > the presence of multicore systems exposed the issues. > Ok, so we should look more into using a newer version of RXTX. The current version from the webpage is 2.2pre2, what is the stability status of this version. Is it good enough for use in a production environment? -- Kjetil ?ster?s From martinezrodolfo at gmail.com Fri Sep 4 13:39:57 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Fri, 4 Sep 2009 15:09:57 -0430 Subject: [Rxtx] Problem with data available event Message-ID: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Hello list members. I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a serial port USB adapter to communicate with an electronical inmunoassay analyzer. The program works porperly with one model of the analyzer series. It defines a protocol which every message sent should be replied with an ACK in order to continue with the communication. Now we are trying to communicate with another model of the same brand and series wich in theory should be much of the same of what was previously done. Unfortunately, that is not the case. The problem with this connection is that it never fires the Data Available serial port event. Is like if nothing was being received in the input stream. The following code always prints zero when the equipment should be transmitting. ----------------------- beginning of sample code ---------------------------------- SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", 10000); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); int len = 0; byte[] readBuffer = new byte[8]; while (true) { len = in.read(readBuffer); System.out.println(len); writer.writeACK(); // writing ACK to analyzer } ----------------------- end of sample code ------------------------------------------ We know that the analyzer is transmitting because HyperTerminal does shows the proper output. In fact, after running the above code and connecting via Hyperterminal all data is received in one block. Is like the data sent from the analyzer is being held somewhere in the way. Sniffing at the serial port, noticed that IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this helps to find what might be wrong or not, but here they are: On Hyperterminal: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 XonLimit:80 XoffLimit:200 On Java: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 XonLimit:0 XoffLimit:0 Thanks in advance for your help. Rodolfo M From ilkka at myller.com Sat Sep 5 04:36:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 5 Sep 2009 13:36:27 +0300 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <121198EE-65A4-463B-ACC7-29FFB9855B2C@myller.com> Hi Rodolfo, By default RXTX does not enable any flow control for the serial port. Please check what flow control you have active in HyperTerminal when you are able to receive data and then use the same flow control with RXTX serial port: serialPort.setFlowControlMode(int flowcontrol); Possible flowcontrol flags are (from SerialPort class) FLOWCONTROL_NONE FLOWCONTROL_RTSCTS_IN FLOWCONTROL_RTSCTS_OUT FLOWCONTROL_XONXOFF_IN FLOWCONTROL_XONXOFF_OUT For example, you can try enabling RTS/CTS hardware flow control. Note the bitwise OR operator ' | ': serialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Also if your device requires RTS/CTS flow control make sure you have fully connected serial cable (not just RX, TX, GND for example, but also RTS, CTS, DTR). One thing you might want to check is the state of DTR (Data Terminal Ready). Some devices wait for the DTR signal before they send any data. You can enable or disable DTR signal (high/low) with: serialPort.setDTR( boolean state ); -- I > Hello list members. > > I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a > serial port USB adapter to communicate with an electronical > inmunoassay analyzer. The program works porperly with one model of the > analyzer series. It defines a protocol which every message sent should > be replied with an ACK in order to continue with the communication. > Now we are trying to communicate with another model of the same brand > and series wich in theory should be much of the same of what was > previously done. Unfortunately, that is not the case. The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. > > ----------------------- beginning of sample code > ---------------------------------- > SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", > 10000); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > InputStream in = serialPort.getInputStream(); > OutputStream out = serialPort.getOutputStream(); > > int len = 0; > byte[] readBuffer = new byte[8]; > while (true) { > len = in.read(readBuffer); > System.out.println(len); > > writer.writeACK(); // writing ACK to analyzer > } > ----------------------- end of sample code > ------------------------------------------ > > We know that the analyzer is transmitting because HyperTerminal does > shows the proper output. In fact, after running the above code and > connecting via Hyperterminal all data is received in one block. Is > like the data sent from the analyzer is being held somewhere in the > way. Sniffing at the serial port, noticed that > IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this > helps to find what might be wrong or not, but here they are: > > On Hyperterminal: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 > XonLimit:80 XoffLimit:200 > > On Java: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 > XonLimit:0 XoffLimit:0 > > > Thanks in advance for your help. > Rodolfo M > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.weber99 at gmx.net Sun Sep 6 13:51:12 2009 From: karl.weber99 at gmx.net (Karl Weber) Date: Sun, 6 Sep 2009 21:51:12 +0200 Subject: [Rxtx] Cannot create lock file Message-ID: <200909062151.12228.karl.weber99@gmx.net> Hi, I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an opensuse repository as well as from the homepage of the rxtx project. I have already added the user to the group uucp, however, it does not have any effect. What else do I have to do to make it work? (It does work with user root, though.) The error message is: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL Thanks in advance, Karl From tjarvi at qbang.org Sun Sep 6 13:51:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 6 Sep 2009 13:51:42 -0600 (MDT) Subject: [Rxtx] Cannot create lock file In-Reply-To: <200909062151.12228.karl.weber99@gmx.net> References: <200909062151.12228.karl.weber99@gmx.net> Message-ID: On Sun, 6 Sep 2009, Karl Weber wrote: > Hi, > > I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an > opensuse repository as well as from the homepage of the rxtx project. > > I have already added the user to the group uucp, however, it does not have > any effect. What else do I have to do to make it work? (It does work with > user root, though.) > > The error message is: > > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to > create lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > > Thanks in advance, Karl Look at the group that owns /var/lock with ls -ld /var/lock The following should work as a user when they are in the correct group: touch /var/lock/test && rm -f /var/lock/test -- Trent Jarvi tjarvi at qbang.org From Luca.Catoni at sysdat.it Mon Sep 7 06:32:42 2009 From: Luca.Catoni at sysdat.it (Luca Catoni) Date: Mon, 7 Sep 2009 14:32:42 +0200 Subject: [Rxtx] time-out implementation Message-ID: I need to implement a simple timer class to manage time-out in my RS-232 serial communication with a remote device using the rxtx library. The functions that the timer should have are start(), and reset() and start() method must throw an exception (TimeoutException) when it expires. I am not an expert in concurrent programming and I do not have much knowledge on threads. myTimer.setExpirationTime(myvalue); ? public void serialEvent(SerialPortEvent event) { if (event.getEventType() == SerialPortEvent.OUTPUT_BUFFER_EMPTY) { // transmission ? out.write(?); try{ myTimer.start(); }catch(TimeoutException te){ myTimer.reset(); ? } ? if (event.getEventType() == SerialPortEvent.DATA_AVAILABLE) { // receiving in.read(?); if (mycondition){ myTimer.stop();//ok, timer NOT expired myTimer.reset();//now I can call start() method again in //transmission to restart my timer when I //have to transmit next data } Can anyone help me to implement the class MyTimer? thanks in advance. -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Mon Sep 7 06:49:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Mon, 7 Sep 2009 18:19:24 +0530 Subject: [Rxtx] 2.2Pre + MacMini+ Deadlock while second time port Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E22FB6F@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, Please find the updated code (close call was commented by mistake). This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From michael.erskine at ketech.com Mon Sep 7 09:13:03 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 7 Sep 2009 16:13:03 +0100 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Rodolfo Mart?nez > Subject: [Rxtx] Problem with data available event > The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. Hi Rodolfo, The sample code you provided doesn't implement or register any event listeners. Regards, Michael Erskine. From martinezrodolfo at gmail.com Mon Sep 7 10:21:22 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Mon, 7 Sep 2009 11:51:22 -0430 Subject: [Rxtx] Problem with data available event In-Reply-To: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> Message-ID: <30eacee0909070921l7f285765ue2c661963183fd2b@mail.gmail.com> On Mon, Sep 7, 2009 at 10:43 AM, Michael Erskine wrote: > Hi Rodolfo, > The sample code you provided doesn't implement or register any event listeners. > > Regards, > Michael Erskine. Hi Michael, I didn't write the event listeners declaration on the sample code for simplicity, but I do implement them on my real code. I should have mentioned it on the sample code anyway... my bad. I haven't had access to the device I'm trying to connect, but tomorrow will. And hope that with the explanation of Ilkka Myller will succeed this time. Thanks for your attention. Rodolfo M From ajmas at sympatico.ca Mon Sep 7 16:58:13 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 7 Sep 2009 18:58:13 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" I noticed in the page you posted posted you indicated that you patched two files. Did you submit the changes to Jarvi, so they could be included in the main code branch? Andr? From tjarvi at qbang.org Mon Sep 7 16:57:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Sep 2009 16:57:53 -0600 (MDT) Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On Mon, 7 Sep 2009, Andre-John Mas wrote: > > On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > >> Sorry, my rudeness was not intentional (a typo). >> Lets try again.. ;) >> >> "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > I noticed in the page you posted posted you indicated that you patched two > files. Did you submit the changes to Jarvi, so they could be included in the > main code branch? > Hi Andr? Ilkka is working with us to get changes in. I'm not sure about those two patches which may already be in CVS. I'll let him answer that. I've given him write access to CVS and asked him to cc the list non whitespace changes when they are ready. Right now he is asking questions off the list regarding cleaning up the Mac and w32 build files. -- Trent Jarvi tjarvi at qbang.org From nsp25 at cornell.edu Mon Sep 7 21:17:45 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Mon, 7 Sep 2009 23:17:45 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: (Sorry if this is a double post, but I sent my original message without subscribing, and since this is an urgent problem, I thought I'd resend after subscribing to bypass the moderator limbo zone) Hi all, I've asked my question on StackOverflow already, so rather than copy-paste the question here, I'd like to redirect you there . Short version, I am no longer able to receive anything over RS-232 with RXTX, but other programs work fine. I'm definitely sending things, because when I connect with a different program, all the responses to the commands I sent via RXTX arrive all at once. Everything was fine in the spring, so what could have happened? Windows update? -Nate -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.j.tandy at warwick.ac.uk Tue Sep 8 01:30:48 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Tue, 8 Sep 2009 08:30:48 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> OK, so: 1. It worked in spring but has stopped doing so and 2. The data all arrives at once when you start hyperterminal. Is it possible you're using a different serial cable to connect to the device, compared to the one you were using in spring? If so, the issue might be hardware flow control - that is, your device might be buffering data because it can't transmit it until your computer sets 'DTR' or 'RTS' or something like that. One way of bypassing hardware flow control is by using cables which cross over certain wires so that the right signals are always being sent; it's possible your old cable had these connections but your current cable doesn't have them. If you can find the old cable, you could put it back in and see if that fixes things? 2009/9/8 Nathaniel S. Parsons : > (Sorry if this is a double post, but I sent my original message without > subscribing, and since this is an urgent problem, I thought I'd resend after > subscribing to bypass the moderator limbo zone) > > Hi all, > > I've asked my question on StackOverflow already, so rather than copy-paste > the question here, I'd like to redirect you there. > > Short version, I am no longer able to receive anything over RS-232 with > RXTX, but other programs work fine. I'm definitely sending things, because > when I connect with a different program, all the responses to the commands I > sent via RXTX arrive all at once. > > Everything was fine in the spring, so what could have happened? Windows > update? > > -Nate > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Tue Sep 8 01:50:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 8 Sep 2009 10:50:33 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <111FEC9A-26BA-435C-BABC-314C7E4F23E5@myller.com> Hi all, Patches applied to the 2.1.7 binaries distributed by Robert Harder (http://iharder.sourceforge.net/current/java/ ) are already in the 2.2. Actually in 2.2 the issue with integer types handling seems to be fixed even more extensively than that single patch to 2.1.7 originally did. And yes, Trent has granted me CVS commit access. Thank you. First thing I'm going to focus on is the code quality and clean up: unused variables, invalid pointer usage etc.. Most of this just causing compile warnings - some harmless and some have potential for causing runtime problems. Instead of just blindly committing new changes to CVS, I've been discussing with Trent about the way things have been done in the RXTX CVS before. (how to handle white space patches, what needs to be discussed with the list first, proper locations for new files/ directories/subprojects, "the way things are done in RXTX"). But patches are coming and bugs will be fixed. I hope everyone will continue to submit the bugs they discover to this mailing list. Most important thing is to provide enough info (code;) so that the issue can be duplicated and eventually fixed. -- I > > > On Mon, 7 Sep 2009, Andre-John Mas wrote: >> >> I noticed in the page you posted posted you indicated that you >> patched two files. Did you submit the changes to Jarvi, so they >> could be included in the main code branch? >> > > Ilkka is working with us to get changes in. I'm not sure about > those two patches which may already be in CVS. I'll let him answer > that. > > I've given him write access to CVS and asked him to cc the list non > whitespace changes when they are ready. Right now he is asking > questions off the list regarding cleaning up the Mac and w32 build > files. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 15:35:19 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 17:35:19 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: Thanks for the response. I'll try to get to the electronics store tomorrow to get more serial cables, even if it isn't the problem. I am using a different serial cable than I was in the spring. It's actually a Male/Female cable with a female-female adapter since the old cables aren't around anymore. The hardware's manual says nothing except to use a "Straight cable" but I figured that if it worked in HyperTerminal, it should work in RXTX, right? Anyways, I've also noticed some things that are different between HyperTerminal, RXTX, and a separate program I found that communicates with the device (but doesn't do what I want, which is why I'm rolling my own program) HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and DTR indicators are green Other program - not sure what settings it thinks it's using, but only SPM's RTS indicator is green RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators are on. >From Serial Port Monitor's help files (paraphrased): the indicators display the state of the serial control lines RTS - Request To Send CTS - Clear To Send DTR - Data Terminal Ready Could this be related to the problem? -Nate On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > OK, so: > > 1. It worked in spring but has stopped doing so and > 2. The data all arrives at once when you start hyperterminal. > > Is it possible you're using a different serial cable to connect to the > device, compared to the one you were using in spring? > > If so, the issue might be hardware flow control - that is, your device > might be buffering data because it can't transmit it until your > computer sets 'DTR' or 'RTS' or something like that. > > One way of bypassing hardware flow control is by using cables which > cross over certain wires so that the right signals are always being > sent; it's possible your old cable had these connections but your > current cable doesn't have them. If you can find the old cable, you > could put it back in and see if that fixes things? > > > 2009/9/8 Nathaniel S. Parsons : > > (Sorry if this is a double post, but I sent my original message without > > subscribing, and since this is an urgent problem, I thought I'd resend > after > > subscribing to bypass the moderator limbo zone) > > > > Hi all, > > > > I've asked my question on StackOverflow already, so rather than > copy-paste > > the question here, I'd like to redirect you there. > > > > Short version, I am no longer able to receive anything over RS-232 with > > RXTX, but other programs work fine. I'm definitely sending things, > because > > when I connect with a different program, all the responses to the > commands I > > sent via RXTX arrive all at once. > > > > Everything was fine in the spring, so what could have happened? Windows > > update? > > > > -Nate > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 18:57:58 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 20:57:58 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: I added a call to setRTS() but nothing changed in Serial Port Monitor, no matter what the argument was. Is this a bug, or did I call the wrong function? I tried to find the c code behind this function, and I think I found it in rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong to me. Am I looking at the right function or is the problem somewhere else? -Nate On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons wrote: > Thanks for the response. I'll try to get to the electronics store tomorrow > to get more serial cables, even if it isn't the problem. > > I am using a different serial cable than I was in the spring. It's actually > a Male/Female cable with a female-female adapter since the old cables aren't > around anymore. The hardware's manual says nothing except to use a "Straight > cable" but I figured that if it worked in HyperTerminal, it should work in > RXTX, right? > > Anyways, I've also noticed some things that are different between > HyperTerminal, RXTX, and a separate program I found that communicates with > the device (but doesn't do what I want, which is why I'm rolling my own > program) > > HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and > DTR indicators are green > Other program - not sure what settings it thinks it's using, but only SPM's > RTS indicator is green > RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators > are on. > > From Serial Port Monitor's help files (paraphrased): the indicators display > the state of the serial control lines > > RTS - Request To Send > CTS - Clear To Send > DTR - Data Terminal Ready > > Could this be related to the problem? > > -Nate > > > On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > >> OK, so: >> >> 1. It worked in spring but has stopped doing so and >> 2. The data all arrives at once when you start hyperterminal. >> >> Is it possible you're using a different serial cable to connect to the >> device, compared to the one you were using in spring? >> >> If so, the issue might be hardware flow control - that is, your device >> might be buffering data because it can't transmit it until your >> computer sets 'DTR' or 'RTS' or something like that. >> >> One way of bypassing hardware flow control is by using cables which >> cross over certain wires so that the right signals are always being >> sent; it's possible your old cable had these connections but your >> current cable doesn't have them. If you can find the old cable, you >> could put it back in and see if that fixes things? >> >> >> 2009/9/8 Nathaniel S. Parsons : >> > (Sorry if this is a double post, but I sent my original message without >> > subscribing, and since this is an urgent problem, I thought I'd resend >> after >> > subscribing to bypass the moderator limbo zone) >> > >> > Hi all, >> > >> > I've asked my question on StackOverflow already, so rather than >> copy-paste >> > the question here, I'd like to redirect you there. >> > >> > Short version, I am no longer able to receive anything over RS-232 with >> > RXTX, but other programs work fine. I'm definitely sending things, >> because >> > when I connect with a different program, all the responses to the >> commands I >> > sent via RXTX arrive all at once. >> > >> > Everything was fine in the spring, so what could have happened? Windows >> > update? >> > >> > -Nate >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Tue Sep 8 21:54:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 21:54:26 -0600 (MDT) Subject: [Rxtx] rxtx is moving to the clouds Message-ID: rxtx is moving onto a cloud server. You may notice short outages as things move around. So far the following is done. http://rxtx.qbang.org (will redirect rxtx.org there for 2.2) http://bugzilla.qbang.org (bugs) The mail-list is tomorrow night. CVS and FTP will be last. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 8 22:03:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 22:03:26 -0600 (MDT) Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: On Tue, 8 Sep 2009, Nathaniel S. Parsons wrote: > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? Hi Nathaniel, That depends upon what you are running. WinCE is for embedded windows. The Windows source is in src/termios.c (called from src/SerialImp.c). -- Trent Jarvi tjarvi at qbang.org From m.j.tandy at warwick.ac.uk Wed Sep 9 03:27:10 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 10:27:10 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> I had a similar problem a while ago - hardware that would work with Hyperterminal but not with Rxtx. I don't know if this is a bug in RxTx or not - I tried to find where in the RxTx source code those functions are actually implemented - I got as far as the ioctl function in termios.c, where the TIOCMSET case sets the MSR byte in the termios struct, but I can't figure out where that gets written to the dcb struct's fDtrControl dword. It could be a bug, or it could just be me missing something. In any case, at the time I had this problem I wasn't equipped to debug RxTx so instead I created a special cable to satisfy the hardware's flow control while leaving the data connection straight through. Here's how I connected it: At the female end of the cable (i.e. the hardware I was connecting to) I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. I connected the ground and data pins straight through - that is, pin 5 female end to pin 5 male end, pin 2 female end to pin 2 male end, pin 3 female end to pin 3 male end. Anyway, using that cable bypassed the hardware's flow control, and got RxTx working just as well as HyperTerminal - although I slowed down my communication to make sure I didn't encounter a situation where the flow control would have come into effect, as I had bypassed it! Hope that helps. 2009/9/9 Nathaniel S. Parsons : > I added a call to setRTS() but nothing changed in Serial Port Monitor, no > matter what the argument was. Is this a bug, or did I call the wrong > function? > > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? > > -Nate > > On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > wrote: >> >> Thanks for the response. I'll try to get to the electronics store tomorrow >> to get more serial cables, even if it isn't the problem. >> >> I am using a different serial cable than I was in the spring. It's >> actually a Male/Female cable with a female-female adapter since the old >> cables aren't around anymore. The hardware's manual says nothing except to >> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >> should work in RXTX, right? >> >> Anyways, I've also noticed some things that are different between >> HyperTerminal, RXTX, and a separate program I found that communicates with >> the device (but doesn't do what I want, which is why I'm rolling my own >> program) >> >> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >> DTR indicators are green >> Other program - not sure what settings it thinks it's using, but only >> SPM's RTS indicator is green >> RXTX - no matter what flow control I set, only SPM's CTS and DTR >> indicators are on. >> >> From Serial Port Monitor's help files (paraphrased): the indicators >> display the state of the serial control lines >> >> RTS - Request To Send >> CTS - Clear To Send >> DTR - Data Terminal Ready >> >> Could this be related to the problem? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> wrote: >>> >>> OK, so: >>> >>> 1. It worked in spring but has stopped doing so and >>> 2. The data all arrives at once when you start hyperterminal. >>> >>> Is it possible you're using a different serial cable to connect to the >>> device, compared to the one you were using in spring? >>> >>> If so, the issue might be hardware flow control - that is, your device >>> might be buffering data because it can't transmit it until your >>> computer sets 'DTR' or 'RTS' or something like that. >>> >>> One way of bypassing hardware flow control is by using cables which >>> cross over certain wires so that the right signals are always being >>> sent; it's possible your old cable had these connections but your >>> current cable doesn't have them. If you can find the old cable, you >>> could put it back in and see if that fixes things? >>> >>> >>> 2009/9/8 Nathaniel S. Parsons : >>> > (Sorry if this is a double post, but I sent my original message without >>> > subscribing, and since this is an urgent problem, I thought I'd resend >>> > after >>> > subscribing to bypass the moderator limbo zone) >>> > >>> > Hi all, >>> > >>> > I've asked my question on StackOverflow already, so rather than >>> > copy-paste >>> > the question here, I'd like to redirect you there. >>> > >>> > Short version, I am no longer able to receive anything over RS-232 with >>> > RXTX, but other programs work fine. I'm definitely sending things, >>> > because >>> > when I connect with a different program, all the responses to the >>> > commands I >>> > sent via RXTX arrive all at once. >>> > >>> > Everything was fine in the spring, so what could have happened? Windows >>> > update? >>> > >>> > -Nate >>> > >>> > _______________________________________________ >>> > Rxtx mailing list >>> > Rxtx at qbang.org >>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>> > >>> > >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Wed Sep 9 03:54:45 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 12:54:45 +0300 Subject: [Rxtx] Xcode 3.x project available in CVS Message-ID: Hi everyone, I've just committed Apple Xcode 3.x (preferably 3.2) compatible project to CVS. The project can be used to develop and build Mac OS X 10.5+ compatible Universal Binary JNI library and RXTXcomm.jar. It's does not have dependencies to existing Autotools based build scripts - only standard Xcode installation is required. The older Xcode 2.x project is still there, but please note that it's not compatible with newer Xcode versions due to its dependency to deprecated Jam build system. The new project is available in rxtx-devel/MACOSX_IDE/Xcode3 How to get the source code from CVS: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Latest Xcode can be downloaded from Apple: http://developer.apple.com/technology/xcode.html -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 05:07:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 14:07:05 +0300 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: Nathaniel, I agree with Michael that your issue is probably with incorrect hardware flow control (RTS/CTS + possibly DTR/DSR). With RXTX you can do things manually, automatically or by mixing both ways. RXTX is "low-level" enough to let developer make those decisions. Which is proper. Automatic hardware flow-control: If you want to do automatic RTS/CTS flow control in both directions (from and to PC) you must set: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Note that you must combine flow control flags with bitwise OR ( ' | ' ) Manual: If you want to bypass all flow controls signals, or handle them manually you must set: setFlowControlMode( SerialPort.FLOWCONTROL_NONE ); In manual mode, you must manually handle controlling signals from PC and reading flow control signals from by the device: RTS - Request To Send -- setRTS() method can used to set this CTS - Clear To Send -- isCTS() method can be used to read this For example, it is entirely possible to manually implement normal RTS/ CTS flow control with RXTX without relying on low-level automatic implementation. Mixed: You can also configure serial port to handle RTS/CTS automatically in only one direction, then you must set one of: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN ); or setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_OUT ); Then you can either ignore or implement manually the flow control scheme in the other direction. DTR and DSR: These are not officially flow control signals, but might affect external devices (disable, standby etc.). Use and meaning of these depends on the device. DTR - Data Terminal Ready -- setDTR() method DSR - Data Set Ready -- setDSR() method CTS/RTS standards: Please note that there are two standard ways RTS/CTS flow control is done (depends on the device): asymmetric (RS-232) symmetric (RS-232-E / TIA-232-E) For more info see: http://en.wikipedia.org/wiki/RS232#RTS.2FCTS_handshaking Some devices may even use RTS/CTS to some other non-standard purpose. With those devices, enabling automatic RTS/CTS could cause very strange behaviour as they clearly require manual control of CTS/RTS. ---- As far as I know, RXTX properly controls all these signals all the way to actual RS232 pins - unless there is a new platform incompatibility bug that I'm not aware of;) Mostly it's just wrong combination and/or usage of these additional signals that cause problems receiving or sending. And the only solution is to really *know* how your device wants these signals handled - and then code your RXTX application accordingly. Creating non-standard cable is not the right solution in my opinion. Unfortunately some applications (like HyperTerminal for example) might hit more or less accidentally to the right combination of RTS/CTS/DTR/ DSR usage and make RXTX look bad in comparison. While all RXTX does by default is - well - nothing. It gives full control the developer. -- I > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port >> Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I >> found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't >> look wrong >> to me. Am I looking at the right function or is the problem >> somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > > >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store >>> tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since >>> the old >>> cables aren't around anymore. The hardware's manual says nothing >>> except to >>> use a "Straight cable" but I figured that if it worked in >>> HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that >>> communicates with >>> the device (but doesn't do what I want, which is why I'm rolling >>> my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's >>> RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but >>> only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> > >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect >>>> to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your >>>> device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>>> (Sorry if this is a double post, but I sent my original message >>>>> without >>>>> subscribing, and since this is an urgent problem, I thought I'd >>>>> resend >>>>> after >>>>> subscribing to bypass the moderator limbo zone) >>>>> >>>>> Hi all, >>>>> >>>>> I've asked my question on StackOverflow already, so rather than >>>>> copy-paste >>>>> the question here, I'd like to redirect you there. >>>>> >>>>> Short version, I am no longer able to receive anything over >>>>> RS-232 with >>>>> RXTX, but other programs work fine. I'm definitely sending things, >>>>> because >>>>> when I connect with a different program, all the responses to the >>>>> commands I >>>>> sent via RXTX arrive all at once. >>>>> >>>>> Everything was fine in the spring, so what could have happened? >>>>> Windows >>>>> update? >>>>> >>>>> -Nate >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 06:11:11 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 15:11:11 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings Message-ID: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Hi, Summary: Patch includes multiple minor code quality improvements and also fixes one possible null pointer segfault on Mac. After this patch, compilation on Mac OS X is error/warning free even with gcc -Wall setting. I'll submit more code quality patches later that focus more on linux/ win/java. Fixes: Code quality: - First level parentheses around assignment used as while-loop truth value - Some printf formats not a string literals and including no format arguments Invalid null pointer usage: - Mac: IOMasterPort was called with (int)NULL which does not always resolve to segfault safe value. Corrected to use MACH_PORT_NULL instead. Patch: The patch is against CVS head (@2009/09/09). Attached patch file is in 'cvs diff -up' format. I'll commit this patch to the CVS later this week if there are no objections. Feel free to comment. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090909.patch Type: application/octet-stream Size: 1966 bytes Desc: not available URL: From m.j.tandy at warwick.ac.uk Wed Sep 9 06:57:55 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 13:57:55 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> OK, I just ran a test with my copy of RxTx and the following program: import gnu.io.*; public class SerialTest { public static void main(String[] args) { try { CommPortIdentifier portid = CommPortIdentifier.getPortIdentifier("COM9"); SerialPort serialPort = (SerialPort)portid.open("Serial port DTR/RTS test", 1000); serialPort.setSerialPortParams(4800, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.disableReceiveTimeout(); for (int i=0 ; i<60 ; i++) { serialPort.setDTR(true); serialPort.setRTS(true); Thread.sleep(1000); serialPort.setDTR(false); serialPort.setRTS(false); Thread.sleep(1000); } } catch (Exception e) { e.printStackTrace(); System.exit(1); } System.exit(0); } } I'm using a USB-serial converter (Prolific PL-2303) and I used a multimeter to check that my DTR and RTS pins were both toggling, and they were - between +7 and -6.4 volts. In other words, on the computer I'm using at the moment, with the version of RxTx I'm using at the moment, setDTR and setRTS both seem to work fine. I don't know if it's worth it for you to perform the same test. I gather there are several different configurations for hardware flow control, (DTR/DSR handshaking as well as RTS/CTS handshaking, handshaking for half-duplex operation, and similar) so the cable that worked for me might still be worth a try. 2009/9/9 Michael Tandy : > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong >> to me. Am I looking at the right function or is the problem somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since the old >>> cables aren't around anymore. The hardware's manual says nothing except to >>> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that communicates with >>> the device (but doesn't do what I want, which is why I'm rolling my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>> > (Sorry if this is a double post, but I sent my original message without >>>> > subscribing, and since this is an urgent problem, I thought I'd resend >>>> > after >>>> > subscribing to bypass the moderator limbo zone) >>>> > >>>> > Hi all, >>>> > >>>> > I've asked my question on StackOverflow already, so rather than >>>> > copy-paste >>>> > the question here, I'd like to redirect you there. >>>> > >>>> > Short version, I am no longer able to receive anything over RS-232 with >>>> > RXTX, but other programs work fine. I'm definitely sending things, >>>> > because >>>> > when I connect with a different program, all the responses to the >>>> > commands I >>>> > sent via RXTX arrive all at once. >>>> > >>>> > Everything was fine in the spring, so what could have happened? Windows >>>> > update? >>>> > >>>> > -Nate >>>> > >>>> > _______________________________________________ >>>> > Rxtx mailing list >>>> > Rxtx at qbang.org >>>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>>> > >>>> > >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > From david at attglobal.net Wed Sep 9 09:17:27 2009 From: david at attglobal.net (David Schmidt) Date: Wed, 09 Sep 2009 11:17:27 -0400 Subject: [Rxtx] 2.2 Release plans Message-ID: <4AA7C707.5060802@attglobal.net> I'm holding off releasing an update to my project (adtpro.sourceforge.net) to support OSX Snow Leopard because I'd like to ship an "official" build of rxtx 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for toggling a port off). CVS is looking great on OSX - thanks to all who have been hard at work on that. I wish there were just one more update - Pre3? :-) My question... If I wanted to make a release in, say, a week... would it pay to wait for rxtx, or should I plan to build and ship a local build of 2.2 out of CVS myself? - David Schmidt From tjarvi at qbang.org Wed Sep 9 19:14:29 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:14:29 -0600 (MDT) Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: On Wed, 9 Sep 2009, Ilkka Myller wrote: > Hi, > > Summary: > > Patch includes multiple minor code quality improvements and also fixes one > possible null pointer segfault on Mac. > After this patch, compilation on Mac OS X is error/warning free even with gcc > -Wall setting. > I'll submit more code quality patches later that focus more on > linux/win/java. > > Fixes: > > Code quality: > - First level parentheses around assignment used as while-loop truth value > - Some printf formats not a string literals and including no format arguments > > Invalid null pointer usage: > - Mac: IOMasterPort was called with (int)NULL which does not always resolve > to segfault safe value. Corrected to use MACH_PORT_NULL instead. > > Patch: > > The patch is against CVS head (@2009/09/09). > Attached patch file is in 'cvs diff -up' format. > > I'll commit this patch to the CVS later this week if there are no objections. > Feel free to comment. > These ifdefs can go. If you like I can remove them when you are done. #ifdef DEBUG_MW mexErrMsgTxt( msg ); #else They are just printf like debug messages for use in an environment in which I could not get directly to stderr/stdout. I don't think anyone uses them anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Sep 9 19:17:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:17:43 -0600 (MDT) Subject: [Rxtx] 2.2 Release plans In-Reply-To: <4AA7C707.5060802@attglobal.net> References: <4AA7C707.5060802@attglobal.net> Message-ID: On Wed, 9 Sep 2009, David Schmidt wrote: > I'm holding off releasing an update to my project (adtpro.sourceforge.net) to > support OSX Snow Leopard because I'd like to ship an "official" build of rxtx > 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for > toggling a port off). CVS is looking great on OSX - thanks to all who have > been hard at work on that. I wish there were just one more update - Pre3? > :-) > > My question... If I wanted to make a release in, say, a week... would it pay > to wait for rxtx, or should I plan to build and ship a local build of 2.2 out > of CVS myself? > Hi David, I would suggest planning on shipping a local build in a 1 week timeframe. We could put another prerelease up but there are still fixes coming in. -- Trent Jarvi tjarvi at qbang.org From ilkka at myller.com Wed Sep 9 23:07:34 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:07:34 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: <04A41559-598C-4B6E-821A-DA90CB6228E7@myller.com> Patch (im-20090909.patch) has been committed to the CVS. Trent: I'll include DEBUG_MW cleanup to my next patch. > > On Wed, 9 Sep 2009, Ilkka Myller wrote: > >> Hi, >> >> Summary: >> >> Patch includes multiple minor code quality improvements and also >> fixes one possible null pointer segfault on Mac. >> After this patch, compilation on Mac OS X is error/warning free >> even with gcc -Wall setting. >> I'll submit more code quality patches later that focus more on >> linux/win/java. >> >> Fixes: >> >> Code quality: >> - First level parentheses around assignment used as while-loop >> truth value >> - Some printf formats not a string literals and including no format >> arguments >> >> Invalid null pointer usage: >> - Mac: IOMasterPort was called with (int)NULL which does not always >> resolve to segfault safe value. Corrected to use MACH_PORT_NULL >> instead. >> >> Patch: >> >> The patch is against CVS head (@2009/09/09). >> Attached patch file is in 'cvs diff -up' format. >> >> I'll commit this patch to the CVS later this week if there are no >> objections. >> Feel free to comment. >> > > These ifdefs can go. If you like I can remove them when you are done. > > #ifdef DEBUG_MW > mexErrMsgTxt( msg ); > #else > > They are just printf like debug messages for use in an environment > in which I could not get directly to stderr/stdout. I don't think > anyone uses them anymore. > > -- > Trent Jarvi > tjarvi at qbang.org From ilkka at myller.com Wed Sep 9 23:35:13 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:35:13 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= Message-ID: Hi, Summary: Patch fixes compiling on Linux distributions/kernels that dont ship with linux/utsrelease.h header and therefore have no UTS_RELEASE defined. Usually this applies only to newer distributions and/or kernels - for example Ubuntu 9.04. Fixes: The UTS_RELEASE vs uname checking in initialization functions is now done only in debug build and only when UTS_RELEASE is actually defined. Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910.patch Type: application/octet-stream Size: 9542 bytes Desc: not available URL: From ilkka at myller.com Thu Sep 10 06:43:02 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 15:43:02 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= In-Reply-To: References: Message-ID: Patch has been committed to CVS. > Hi, > > Summary: > > Patch fixes compiling on Linux distributions/kernels that dont ship > with linux/utsrelease.h header and therefore have no UTS_RELEASE > defined. > Usually this applies only to newer distributions and/or kernels - > for example Ubuntu 9.04. > > Fixes: > > The UTS_RELEASE vs uname checking in initialization functions is now > done only in debug build and only when UTS_RELEASE is actually > defined. > > Patch: > > The patch is against CVS head (@2009/09/10). > Attached patch file is in 'cvs diff -up' format. > > > Thanks, > > -- > I > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Thu Sep 10 09:08:01 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 18:08:01 +0300 Subject: [Rxtx] [Patch] Remove unused MathWorks MATLAB DEBUG_MW ifdefs Message-ID: <6DB57DB1-A47E-4435-9CD6-212B671A2849@myller.com> Summary: Patch removes unused MathWorks MATLAB timing debug ifdefs (DEBUG_MW). This is a request from Trent. Fixes: - Removes DEBUG_MW definitions - Removes unused mex....() function definitions - Corrects DEBUG_TIMING to work properly without mexPrintf (with Mac OS X specific format string fixes included) - Removes unused/duplicate timeval struct and DEBUG_TIMING definitions from SerialImp.c and SerialImp.h - Corrects fprintf call in SerialImp.cpp Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910b.patch Type: application/octet-stream Size: 9841 bytes Desc: not available URL: From Kapil_Gupta at hcl.in Thu Sep 10 10:25:29 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 10 Sep 2009 21:55:29 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, I am getting some problem with RXTX on macintosh (reading some data from the device attached to the usb port through usb to serial mechanism). I used the RXTX 2.1.7 then I got PortInUseException but after using 2.2pre it worked fine. But it works only for the first time, it hangs in the second time while opening the port. Please find the attached code. This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Thu Sep 10 13:00:14 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 22:00:14 +0300 Subject: [Rxtx] [Patch] Implement return value checking to file I/O calls Message-ID: Summary: The return value of some functions should always be used. For example, it is dangerous to not check the return value of a write(), read(), open(), fscanf() calls. This patch fixes such occurences in RXTX code. For example: unchecked read() call could result in later - and often seemingly unrelated - segfault due to undefined read buffer contents. After this patch the Linux build process is error/warning free even with gcc -Wall -Werror. Fixes: - Implemented return value checking to file I/O calls in SerialImp.c:fhs_lock(), uucp_lock() and is_device_locked() functions. - Added error recovery for fuserImp.c fscanf() calls. Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910c.patch Type: application/octet-stream Size: 3370 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Thu Sep 10 13:08:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 22:08:05 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> Hi Kapil, I believe this issue has been fixed in CVS version, but still exists in 2.2pre2 available from RXTX wiki. For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html As you've seen from the recent patches announced on this list, we are working very hard to make a new 2.2pre(?) release available. Meanwhile, you can compile your own RXTX binaries from CVS source. On Mac it should be exceptionally easy with new Xcode 3.x project files. Thank you for your patience, -- I > > I am getting some problem with RXTX on macintosh (reading some data > from the device attached to the usb port through usb to serial > mechanism). I used the RXTX 2.1.7 then I got PortInUseException but > after using 2.2pre it worked fine. But it works only for the first > time, it hangs in the second time while opening the port. From ilkka at myller.com Fri Sep 11 04:07:22 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 13:07:22 +0300 Subject: [Rxtx] [Patch] Windows build improvements (MinGW32, MSVC and LCC) Message-ID: <81D06766-8D51-485A-B2A2-624C8EA690BA@myller.com> Summary: Fixes various compiler warnings with Windows builds. Removes unused code blocks from compilation. After this patch the Windows build process is error/warning free with MinGW32, MSVC and LCC compilers - even with -Wall enabled. Does not fix: Latest LCC compiler version still fails even after this patch due to compiler trap error. Trap error does not specify source code location - it fails outputting SerialImp.obj binary. Compiling SerialImp.c without binary output works. Could this be a bug in LCC? Tested with clean RXTX source, latest standard LCC installation and with both Windows Vista SP1 x86 and Windows XP SP3 x86. Patch: The patch is against CVS (@2009/09/11). Attached patch file is in 'cvs diff -up' format. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090911.patch Type: application/octet-stream Size: 6673 bytes Desc: not available URL: From Kapil_Gupta at hcl.in Fri Sep 11 08:21:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Fri, 11 Sep 2009 19:51:24 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Ilkka, I tried getting the source code from the CVS but we could not able to do so, the CVS was not responding. Then we downloaded the 2.2 pre2 code and made the changes that are described in http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html but the problem didn't change. First time the device responds well and the second time it hangs. Did you see the code that we have sent to you, so that you can suggest if we are doing something wrong in our code. Again attaching if you have deleted that. Please suggest (does the CVS code can help rather using the patch provided by you?). Thanks, Kapil -----Original Message----- From: Ilkka Myller [mailto:ilkka at myller.com] Sent: Friday, September 11, 2009 12:38 AM To: Kapil Gupta Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Hi Kapil, I believe this issue has been fixed in CVS version, but still exists in 2.2pre2 available from RXTX wiki. For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html As you've seen from the recent patches announced on this list, we are working very hard to make a new 2.2pre(?) release available. Meanwhile, you can compile your own RXTX binaries from CVS source. On Mac it should be exceptionally easy with new Xcode 3.x project files. Thank you for your patience, -- I > > I am getting some problem with RXTX on macintosh (reading some data > from the device attached to the usb port through usb to serial > mechanism). I used the RXTX 2.1.7 then I got PortInUseException but > after using 2.2pre it worked fine. But it works only for the first > time, it hangs in the second time while opening the port. DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Fri Sep 11 09:33:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 18:33:33 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Hi Kapil, For CVS: Instructions at the old rxtx website are incorrect. Trent updated them, but to a wrong server address "qgang.org" -- the correct server is "qbang.org". Please follow instructions from rxtx wiki: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code About testing your code: When I have time (maybe this weekend), I'll test your code using Mac OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. What USB serial port you are using with your Mac? Something with FTDI chip? or maybe Prolific? What adapter driver version you are using? Just asking, so I can test with the same configuration. Meanwhile I suggest you: - Make sure you have the latest USB Serial adapter drivers, so we can eliminate past issues with those. - Check that you are not having multiple copies of librxtxSerial.jnilib (possibly different versions) in your java library path (=trouble;) - Check for any USB Serial adaptors kernel extension error messages in system log after testing your software (use Console.app to browse logs) -- I Kapil Gupta kirjoitti 11.9.2009 kello 17.21: > Hi Ilkka, > > I tried getting the source code from the CVS but we could not able > to do so, the CVS was not responding. Then we downloaded the 2.2 > pre2 code and made the changes that are described in http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html > but the problem didn't change. First time the device responds well > and the second time it hangs. > > Did you see the code that we have sent to you, so that you can > suggest if we are doing something wrong in our code. Again attaching > if you have deleted that. Please suggest (does the CVS code can help > rather using the patch provided by you?). > > Thanks, > Kapil > > -----Original Message----- > From: Ilkka Myller [mailto:ilkka at myller.com] > Sent: Friday, September 11, 2009 12:38 AM > To: Kapil Gupta > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second > time port open > > Hi Kapil, > > I believe this issue has been fixed in CVS version, but still exists > in 2.2pre2 available from RXTX wiki. > > For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html > > As you've seen from the recent patches announced on this list, we are > working very hard to make a new 2.2pre(?) release available. > > Meanwhile, you can compile your own RXTX binaries from CVS source. On > Mac it should be exceptionally easy with new Xcode 3.x project files. > > > Thank you for your patience, > > > -- > I > > >> >> I am getting some problem with RXTX on macintosh (reading some data >> from the device attached to the usb port through usb to serial >> mechanism). I used the RXTX 2.1.7 then I got PortInUseException but >> after using 2.2pre it worked fine. But it works only for the first >> time, it hangs in the second time while opening the port. > > > DISCLAIMER: > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential > and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of this > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > ----------------------------------------------------------------------------------------------------------------------- > From ilkka at myller.com Fri Sep 11 11:51:13 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 20:51:13 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Message-ID: <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> Ok, I debugged your code on Mac using USB-RS232 adapter + loopback adapter. My findings: there are no issues with RXTX in your code -- there are issues with threading and synchronization. Primary issue: you essentially lock the JVM main thread to 100% CPU usage with infinite loop: while (!processCompleted) { ; } Now.. I'm going to give you a bad advice, mostly because you have bigger threading issues there.. but we must continue somehow: A quick remedy to previous is: while (!processCompleted) { Thread.yield(); } Thread yielding gives other threads atleast a chance to run (and to processCompleted boolean to actually update in main thread context). What happens next is that your main-thread is allowed to continue and proceeds to closeConnection() call it otherwise would never reach. After that, connection closes properly.. main() method continues to "System.out.println(result);" and proceeds to exit JVM.. .. except.. Secondary issue: Exit is one thing JVM cant do since you have left a Timer thread hanging without proper closing in getData() method. Cancel it (uncomment that line) - and your code completes main() to a clean JVM exit. So, my advice to you is to focus on fixing threading, timers and synchronization. Design those well and everything works. Multithreading, done well or not, will not usually confuse RXTX ... but your own code might not be so lucky. -- I > > When I have time (maybe this weekend), I'll test your code using Mac > OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. >> >> Did you see the code that we have sent to you, so that you can >> suggest if we are doing something wrong in our code. Again >> attaching if you have deleted that. Please suggest (does the CVS >> code can help rather using the patch provided by you?). -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 11 15:19:26 2009 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 11 Sep 2009 17:19:26 -0400 Subject: [Rxtx] Can't run my Netbeans/Java s/w on a MAC Message-ID: <4AAABEDE.7020508@howardz.com> An HTML attachment was scrubbed... URL: From ilkka at myller.com Fri Sep 11 15:41:10 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 12 Sep 2009 00:41:10 +0300 Subject: [Rxtx] Can't run my Netbeans/Java s/w on a MAC In-Reply-To: <4AAABEDE.7020508@howardz.com> References: <4AAABEDE.7020508@howardz.com> Message-ID: <35D4BD73-B8CC-4DEE-A846-8858C9C9EBC7@myller.com> Hi, The bug that causes the segfault (invalid memory access) has been fixed (in CVS): http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html Next prerelease is coming (soon I hope), but the the 2.2pre2 fails when reopening the serial port on Mac OS X. -- I > > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] Jar > version = RXTX-2.2pre1 > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] native > lib Version = RXTX-2.2pre2 > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] Invalid > memory access of location 0x12b5e3938 rip=0x12955012f > 9/6/09 3:46:00 PM ReportCrash[6164] Saved crash report for java > [6162] version 13.0.0 (13.0.0) to /Users/myles/Library/Logs/ > DiagnosticReports/java_2009-09-06-154600_myles-PowerBook-PP-108.crash -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Fri Sep 11 20:15:31 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 11 Sep 2009 20:15:31 -0600 (MDT) Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Message-ID: On Fri, 11 Sep 2009, Ilkka Myller wrote: > Hi Kapil, > > For CVS: > > Instructions at the old rxtx website are incorrect. Trent updated them, but > to a wrong server address "qgang.org" -- the correct server is "qbang.org". > Please follow instructions from rxtx wiki: > > http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code The old website has been corrected. -- Trent Jarvi tjarvi at qbang.org From dvd at newfoundmarket.com Sat Sep 12 11:49:48 2009 From: dvd at newfoundmarket.com (DVD) Date: Sat, 12 Sep 2009 13:49:48 -0400 Subject: [Rxtx] RXTX on linux hang Message-ID: <4AABDF3C.2040908@newfoundmarket.com> Hello: I just did a fresh install of RXTZ on both Ubuntu and centos, Java version 6, update 12 I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with the Usage example from your website Two way communcation with the serial port I used the computer's serial port /dev/ttyS0, with UART 16550A the program simply hang. The port was opened and both input/output streamed were opened but the writing/reading are not working. Any help would be appreciated. I tried this program on windows and it worked fine. Thanks From ilkka at myller.com Sat Sep 12 15:31:26 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sun, 13 Sep 2009 00:31:26 +0300 Subject: [Rxtx] RXTX on linux hang In-Reply-To: <4AABDF3C.2040908@newfoundmarket.com> References: <4AABDF3C.2040908@newfoundmarket.com> Message-ID: Hi, It's very hard to say what could be wrong without more details. Can you tell me more about your Linux setup: - Output of: uname -a - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your test code running) - Output of: cat /proc/tty/driver/serial - Are you you testing with root privileges - What kind of device you are communicating with (or just a loopback dongle)? - Does your device expect some specific flow control and/or specific state of DTR/DSR signals? - Have you tried configuring those flow controls and other RS232 signals in your test code? Did they work? - Do other simple terminal programs work (easiest to try: screen /dev/ ttyS0 )? - What is the CPU usage (use 'top' or some other process monitor your like) of your test software when it "hangs"? I can try to duplicate your issue on Ubuntu 9.04 (both x86 and x86_64), Centos 5 (x86) and Debian 5.0 (x86). I'd prefer to test with the same kind of system you have.. Thanks, -- I > > I just did a fresh install of RXTZ on both Ubuntu and centos, Java > version 6, update 12 > I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with > the Usage example from > your website > > Two way communcation with the serial port > > > I used the computer's serial port /dev/ttyS0, with UART 16550A > > the program simply hang. The port was opened and both input/output > streamed were opened > but the writing/reading are not working. > > Any help would be appreciated. I tried this program on windows and > it worked fine. From dvd at newfoundmarket.com Sat Sep 12 21:20:14 2009 From: dvd at newfoundmarket.com (DVD) Date: Sat, 12 Sep 2009 23:20:14 -0400 Subject: [Rxtx] RXTX on linux hang In-Reply-To: References: <4AABDF3C.2040908@newfoundmarket.com> Message-ID: <4AAC64EE.7050904@newfoundmarket.com> Thank you very much for the steps. It is pin out problem. Again, Thanks. Ilkka Myller wrote: > Hi, > > It's very hard to say what could be wrong without more details. > Can you tell me more about your Linux setup: > > - Output of: uname -a > - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your > test code running) > - Output of: cat /proc/tty/driver/serial > - Are you you testing with root privileges > - What kind of device you are communicating with (or just a loopback > dongle)? > - Does your device expect some specific flow control and/or specific > state of DTR/DSR signals? > - Have you tried configuring those flow controls and other RS232 > signals in your test code? Did they work? > - Do other simple terminal programs work (easiest to try: screen > /dev/ttyS0 )? > - What is the CPU usage (use 'top' or some other process monitor your > like) of your test software when it "hangs"? > > > I can try to duplicate your issue on Ubuntu 9.04 (both x86 and > x86_64), Centos 5 (x86) and Debian 5.0 (x86). > I'd prefer to test with the same kind of system you have.. > > > Thanks, > > -- > I > > >> >> I just did a fresh install of RXTZ on both Ubuntu and centos, Java >> version 6, update 12 >> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with >> the Usage example from >> your website >> >> Two way communcation with the serial port >> >> >> >> I used the computer's serial port /dev/ttyS0, with UART 16550A >> >> the program simply hang. The port was opened and both input/output >> streamed were opened >> but the writing/reading are not working. >> >> Any help would be appreciated. I tried this program on windows and >> it worked fine. > From tjarvi at qbang.org Sun Sep 13 12:06:33 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Sep 2009 12:06:33 -0600 (MDT) Subject: [Rxtx] RXTX on linux hang In-Reply-To: <4AAC64EE.7050904@newfoundmarket.com> References: <4AABDF3C.2040908@newfoundmarket.com> <4AAC64EE.7050904@newfoundmarket.com> Message-ID: Hi, Would it be possible to get a short paragraph from you describing the pinout problem and how you discovered it? We can add that to the wiki to help others get past the problem faster next time. On Sat, 12 Sep 2009, DVD wrote: > Thank you very much for the steps. It is pin out problem. > Again, Thanks. > > Ilkka Myller wrote: >> Hi, >> >> It's very hard to say what could be wrong without more details. >> Can you tell me more about your Linux setup: >> >> - Output of: uname -a >> - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your test >> code running) >> - Output of: cat /proc/tty/driver/serial >> - Are you you testing with root privileges >> - What kind of device you are communicating with (or just a loopback >> dongle)? >> - Does your device expect some specific flow control and/or specific state >> of DTR/DSR signals? >> - Have you tried configuring those flow controls and other RS232 signals in >> your test code? Did they work? >> - Do other simple terminal programs work (easiest to try: screen /dev/ttyS0 >> )? >> - What is the CPU usage (use 'top' or some other process monitor your like) >> of your test software when it "hangs"? >> >> >> I can try to duplicate your issue on Ubuntu 9.04 (both x86 and x86_64), >> Centos 5 (x86) and Debian 5.0 (x86). >> I'd prefer to test with the same kind of system you have.. >> >> >> Thanks, >> >> -- >> I >> >> >>> >>> I just did a fresh install of RXTZ on both Ubuntu and centos, Java version >>> 6, update 12 >>> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with the >>> Usage example from >>> your website >>> >>> Two way communcation with the serial port >>> >>> >>> I used the computer's serial port /dev/ttyS0, with UART 16550A >>> >>> the program simply hang. The port was opened and both input/output >>> streamed were opened >>> but the writing/reading are not working. >>> >>> Any help would be appreciated. I tried this program on windows and it >>> worked fine. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dvd at newfoundmarket.com Sun Sep 13 19:18:08 2009 From: dvd at newfoundmarket.com (DVD) Date: Sun, 13 Sep 2009 21:18:08 -0400 Subject: [Rxtx] RXTX on linux hang In-Reply-To: References: <4AABDF3C.2040908@newfoundmarket.com> <4AAC64EE.7050904@newfoundmarket.com> Message-ID: <4AAD99D0.3030206@newfoundmarket.com> Hello, It was a human mistake during wiring and was discovered after staring at it for a while :-). Nothing technical worth mentioning. Thanks Trent Jarvi wrote: > > Hi, > > Would it be possible to get a short paragraph from you describing the > pinout problem and how you discovered it? We can add that to the wiki > to help others get past the problem faster next time. > > On Sat, 12 Sep 2009, DVD wrote: > >> Thank you very much for the steps. It is pin out problem. >> Again, Thanks. >> >> Ilkka Myller wrote: >>> Hi, >>> >>> It's very hard to say what could be wrong without more details. >>> Can you tell me more about your Linux setup: >>> >>> - Output of: uname -a >>> - Output of: stty -a -F /dev/ttyS0 (if possible: with and without >>> your test code running) >>> - Output of: cat /proc/tty/driver/serial >>> - Are you you testing with root privileges >>> - What kind of device you are communicating with (or just a loopback >>> dongle)? >>> - Does your device expect some specific flow control and/or specific >>> state of DTR/DSR signals? >>> - Have you tried configuring those flow controls and other RS232 >>> signals in your test code? Did they work? >>> - Do other simple terminal programs work (easiest to try: screen >>> /dev/ttyS0 )? >>> - What is the CPU usage (use 'top' or some other process monitor >>> your like) of your test software when it "hangs"? >>> >>> >>> I can try to duplicate your issue on Ubuntu 9.04 (both x86 and >>> x86_64), Centos 5 (x86) and Debian 5.0 (x86). >>> I'd prefer to test with the same kind of system you have.. >>> >>> >>> Thanks, >>> >>> -- >>> I >>> >>> >>>> >>>> I just did a fresh install of RXTZ on both Ubuntu and centos, Java >>>> version 6, update 12 >>>> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with >>>> the Usage example from >>>> your website >>>> >>>> Two way communcation with the serial port >>>> >>>> >>>> I used the computer's serial port /dev/ttyS0, with UART 16550A >>>> >>>> the program simply hang. The port was opened and both input/output >>>> streamed were opened >>>> but the writing/reading are not working. >>>> >>>> Any help would be appreciated. I tried this program on windows and >>>> it worked fine. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From Kapil_Gupta at hcl.in Mon Sep 14 10:37:23 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Mon, 14 Sep 2009 20:07:23 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B30A4F25D@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Ilkka, We have done that also, but no success. I am attaching the code, please check the updated code also. We are not using any FTDI/Prolific chip set. We are using TI chip set. We are having only one copy of JNI lib. No Error in console for kernel driver. Warm Regards, Kapil From: Ilkka Myller [mailto:ilkka at myller.com] Sent: Friday, September 11, 2009 11:21 PM To: Kapil Gupta Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Ok, I debugged your code on Mac using USB-RS232 adapter + loopback adapter. My findings: there are no issues with RXTX in your code -- there are issues with threading and synchronization. Primary issue: you essentially lock the JVM main thread to 100% CPU usage with infinite loop: while (!processCompleted) { ; } Now.. I'm going to give you a bad advice, mostly because you have bigger threading issues there.. but we must continue somehow: A quick remedy to previous is: while (!processCompleted) { Thread.yield(); } Thread yielding gives other threads atleast a chance to run (and to processCompleted boolean to actually update in main thread context). What happens next is that your main-thread is allowed to continue and proceeds to closeConnection() call it otherwise would never reach. After that, connection closes properly.. main() method continues to "System.out.println(result);" and proceeds to exit JVM.. .. except.. Secondary issue: Exit is one thing JVM cant do since you have left a Timer thread hanging without proper closing in getData() method. Cancel it (uncomment that line) - and your code completes main() to a clean JVM exit. So, my advice to you is to focus on fixing threading, timers and synchronization. Design those well and everything works. Multithreading, done well or not, will not usually confuse RXTX ... but your own code might not be so lucky. -- I When I have time (maybe this weekend), I'll test your code using Mac OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. Did you see the code that we have sent to you, so that you can suggest if we are doing something wrong in our code. Again attaching if you have deleted that. Please suggest (does the CVS code can help rather using the patch provided by you?). DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10005 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Mon Sep 14 19:03:55 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 15 Sep 2009 02:03:55 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B30A4F25D@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B30A4F25D@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <989B2FAA-5E5A-4F47-AF23-04CE1A6A20F7@myller.com> Kapil, You did not fix the primary issue. Your while() loop still blocks the main thread and the code is not working for the same reasons I stated before. .. but .. I created a demonstration code, which does not try to duplicate the behaviour of your code, but instead demonstrates few concepts: 1. Safe opening of the serial port with full error checking 2. Proper handling of text encoding using Reader/Writer. If your protocol handles plaintext, I recommend you use encoding capable streams. 3. Asynchronous multi-threaded receiving and transmitting (separate thread for each, with their own packet (=string, in this case) queues) 4. Handling serial port data-available events without blocking the event handler (=event only signals async. receiver) 5. Controlling access to serial port in multithreaded app using ReentrantLock (still allows embedded transmit->receive, as demonstrated) 6. Signaling thread from other thread with wait() -> notify() (demonstrated in serial event handling) The code does one simple thing: sends a US-ASCII encoded string to serial port with CR+LF and expects the same line to be received back. I used simple loopback adapter hardware to test this. Normally, doing just this simple task does not require such heavy multi-threading async. receiver/transmitter structures, but I created them to demonstrate various multi-threading concepts, and how they can be used with RXTX. The code is not perfect, it's still a quick hack to demonstrate few things. For example, it lacks proper error handling and propagation in async. receiver/transmitter. However, this code is "profiler clean". It's threads are mostly idle waiting other threads or actual events from RXTX. No thread is blocked in high CPU-% loops etc. when receiving or sending. This also scales nicely to run on multiple CPU's with modern JVM's. When implementing commercial protocol handlers this is how things should always be. Doing "while(someBoolean) {}" is generally not the correct method to sync things. -- I > Hi Ilkka, > > We have done that also, but no success. I am attaching the code, > please check the updated code also. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 11656 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail4ng at gmail.com Tue Sep 15 05:02:48 2009 From: mail4ng at gmail.com (Daniel Weinand) Date: Tue, 15 Sep 2009 11:02:48 +0200 Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby Message-ID: <4AAF5838.7080707@gmail.com> Hello, i'm using RXTX with a USB to Serial Adapter on Linux and Windows machines. Everything works great. but now i have a problem on a Vista machine with standby mode. after the machine wakes up i'll get an infinite error loop: Error 0x5 at ..\src\termios.c(2712): Access Denied Error 0x5 at ..\src\termios.c(517): Access Denied ... and so on. My Application runs as a windows service and so it tries to enumerate and connect to the port directly after it wakes up. but the Port is blocked until i restart the whole machine and everything starts from 0. i'm using rxtx 2.2pre2 is this a known problem and how to solve this? From tjarvi at qbang.org Tue Sep 1 02:38:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 1 Sep 2009 02:38:40 -0600 (MDT) Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks Ilkka The problem should be resolved (confirmed from two locations). I'll be trying to hunt down a Snow Leopard box tomorrow evening as well. On Tue, 1 Sep 2009, Ilkka Myller wrote: > Hi, > > CVS server is reachable, but when trying anonymous login it replies: > > " > Fatal error, aborting. > anonymous: no such system user > " > > It seems that the anonymous cvs account is not yet properly configured on the > new system. > > -- > I > >> On Mon, 31 Aug 2009, Trent Jarvi wrote: >> >> The server has been beemed to another location for those experiencing >> routing problems. >> >> in bash: >> >> export CVSROOT=:pserver:anonymous at qbang.org:2401/var/cvs/cvsroot >> cvs login (no passwd) >> cvs co -r commapi-0-0-1 rxtx-devel >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Tue Sep 1 03:05:59 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 12:05:59 +0300 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks, The new CVS server works well :) I can also confirm that latest CVS version builds properly with unmodified Snow Leopard (Mac OS X 10.6) system: Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 gcc version 4.2.1 (Apple Inc. build 5646) Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) --> Resulting JNI library (Universal Binary): i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = 9d15fc488b301da8bf65b2c9456a7bbb --> Resulting JAR: RXTXComm.jar / 60942 bytes MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 Atleast it builds.. and probably works too. I have not tested that yet. -- I Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > The problem should be resolved (confirmed from two locations). I'll > be trying to hunt down a Snow Leopard box tomorrow evening as well. From jimmy.lee at emotum.com Tue Sep 1 05:07:19 2009 From: jimmy.lee at emotum.com (Jimmy Lee [emotum]) Date: Tue, 1 Sep 2009 21:07:19 +1000 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: <112685a90909010407i6054acb5tc2b12196797bfaf1@mail.gmail.com> Could we access to the binaries? Please :) 2009/9/1 Ilkka Myller > Thanks, > > The new CVS server works well :) > > I can also confirm that latest CVS version builds properly with unmodified > Snow Leopard (Mac OS X 10.6) system: > > Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_I386 i386 > gcc version 4.2.1 (Apple Inc. build 5646) > Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) > > > --> Resulting JNI library (Universal Binary): > > i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes > > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 > librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc > > MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = > 9d15fc488b301da8bf65b2c9456a7bbb > > > --> Resulting JAR: > > RXTXComm.jar / 60942 bytes > > MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 > > > > Atleast it builds.. and probably works too. I have not tested that yet. > > -- > I > > Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > > The problem should be resolved (confirmed from two locations). I'll be >> trying to hunt down a Snow Leopard box tomorrow evening as well. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Tue Sep 1 06:21:28 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Tue, 1 Sep 2009 08:21:28 -0400 (EDT) Subject: [Rxtx] Snow Leopard binaries Message-ID: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> +1 for binaries - pretty please with sugar on top... -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com From fredm at alum.mit.edu Tue Sep 1 06:24:17 2009 From: fredm at alum.mit.edu (Fred G. Martin) Date: Tue, 1 Sep 2009 08:24:17 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> Message-ID: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> You can find one here: http://iharder.sourceforge.net/current/java/ Also, you need to add yourself (any rxtx user) to the uucp group. Niutils don't exist, but dscl is a replacement. There is info for using it here: http://aplawrence.com/MacOSX/directory_services.html Fred On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Tue Sep 1 07:03:37 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Tue, 1 Sep 2009 18:33:37 +0530 Subject: [Rxtx] Help for RXTX on mac Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time I am able to read the device but on second time, it hangs on COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then it was showing the PortInUseException, I replaced the RXTX library to 2.2Pre1 so it is showing this problem. Is this is a problem with RXTX on Mac? Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: From ilkka at myller.com Tue Sep 1 07:57:06 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 16:57:06 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:02:31 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:02:31 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:43:49 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:43:49 +0300 Subject: [Rxtx] Help for RXTX on mac In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE@myller.com> Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Arseneau at Sun.COM Tue Sep 1 08:51:32 2009 From: Eric.Arseneau at Sun.COM (Eric Arseneau) Date: Tue, 01 Sep 2009 07:51:32 -0700 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24@sun.com> Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 09:24:30 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 18:24:30 +0300 Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D@myller.com> Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Thu Sep 3 02:50:16 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Thu, 3 Sep 2009 10:50:16 +0200 Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s From Kapil_Gupta at hcl.in Thu Sep 3 06:52:21 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:22:21 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From Kapil_Gupta at hcl.in Thu Sep 3 07:15:19 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:45:19 +0530 Subject: [Rxtx] Rxtx Digest, Vol 25, Issue 3 In-Reply-To: References: Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C50BB@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi myller, I have attached the code with the mail. Please help me if I am doing something wrong in it. Thanks & Regards, Kapil Gupta -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of rxtx-request at qbang.org Sent: Thursday, September 03, 2009 4:15 PM To: rxtx at qbang.org Subject: Rxtx Digest, Vol 25, Issue 3 Send Rxtx mailing list submissions to rxtx at qbang.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qbang.org/mailman/listinfo/rxtx or, via email, send a message with subject or body 'help' to rxtx-request at qbang.org You can reach the person managing the list at rxtx-owner at qbang.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Rxtx digest..." Today's Topics: 1. Re: Snow Leopard binaries (Ilkka Myller) 2. Re: Snow Leopard binaries (Ilkka Myller) 3. Re: Help for RXTX on mac (Ilkka Myller) 4. Re: Snow Leopard binaries (Eric Arseneau) 5. Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters (Ilkka Myller) 6. RXTX multiple crashes (Kjetil ?ster?s) 7. RXTX 2.2Pre + MacMini+ Deadlock while second time port open (Kapil Gupta) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Sep 2009 16:57:06 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 1 Sep 2009 17:02:31 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <55EC133D-DC83-45A3-849C-02714904D580 at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 1 Sep 2009 17:43:49 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Help for RXTX on mac Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Tue, 01 Sep 2009 07:51:32 -0700 From: Eric Arseneau Cc: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24 at sun.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 1 Sep 2009 18:24:30 +0300 From: Ilkka Myller To: rxtx Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Thu, 3 Sep 2009 10:50:16 +0200 From: Kjetil ?ster?s To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s ------------------------------ Message: 7 Date: Thu, 3 Sep 2009 18:22:21 +0530 From: Kapil Gupta To: "rxtx at qbang.org" Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059 at NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset="us-ascii" Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: ------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx End of Rxtx Digest, Vol 25, Issue 3 *********************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From ilkka at myller.com Thu Sep 3 11:17:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 3 Sep 2009 20:17:27 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <4520677F-E8F0-46F5-B4AD-3AD3A7C2AED3@myller.com> Hi Kapil, The code is incomplete and I did not find anything I could to test/ debug with this. I also tried to find the actual serial port opening, but found only a call to missing method which creates the SerialPort object (?): serialPort = getSerialPortConnection( COMPort, this.readEvent.getDeviceName(), SerialCommConfig.DEVICE1[SerialCommConfig.TIMEOUT], SerialCommConfig.DEVICE1[SerialCommConfig.BAUDRATE], SerialCommConfig.DEVICE1[SerialCommConfig.DATABITS], SerialCommConfig.DEVICE1[SerialCommConfig.STOPBITS], SerialCommConfig.DEVICE1[SerialCommConfig.PARITY] ); The class SerialCommConfig is missing too. If this is a part of the actual code you are using, please note that you are not actually closing the serial port. The call to close() method is commented out: try { // serialPort.close(); } catch (Exception ex) { ex.printStackTrace(); } Re-opening of the serial port wont work if you haven't properly closed it first. -- I > > I am using RXTX on Macintosh to communicate to my device. First time > the device responds well but on second time, it hangs on > COMPort.open (name, timeout). > > I have attached the source code in a file. Please help me. > > Thanks & Best Regards, > Kapil -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorton at intellimec.com Thu Sep 3 11:37:55 2009 From: dmorton at intellimec.com (Daniel Morton) Date: Thu, 3 Sep 2009 13:37:55 -0400 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. (I haven't tried previous version though). Daniel Morton Java/J2EE Developer Tel +1 519.745.8887 x4331 Email dmorton at intellimec.com www.intellimec.com | www.iLane.com | www.drivesync.com Intelligent Mechatronic Systems Inc. 435 King Street North Waterloo, ON N2J 2Z5 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s Sent: Thursday, September 03, 2009 4:50 AM To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. From alexanderkiel at gmx.net Fri Sep 4 02:29:15 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 10:29:15 +0200 Subject: [Rxtx] Official Javadoc Location Message-ID: <1252052955.4025.80.camel@T61-KIEL> Hi List, I wasn't able to find an official location of RXTX Javadoc accessible over HTTP. Maybe someone can link me to it. If there is no such location, I would like to see one. I like to link from my own Javadoc to such a location. Thanks Alexander - e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:19:25 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:19:25 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> Message-ID: <1252055965.4025.84.camel@T61-KIEL> Hi Michael, thanks for the pointer. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 09:48 +0100, Michael Tandy wrote: > RxTx javadoc: http://users.frii.com/jarvi/rxtx/doc/index.html > Javax interface RxTx duplicates javadoc: > http://java.sun.com/products/javacomm/reference/api/index.html > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:22:14 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:22:14 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> Message-ID: <1252056134.4025.87.camel@T61-KIEL> Hi Eike, thanks, but I need a direct package pointer so that Javadoc will link the gnu.io packages automatically to the right location. Michael has pointed me to http://users.frii.com/jarvi/rxtx/doc/index.html which has the gnu.io packages. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 11:04 +0200, Eike Hinderk J?rrens wrote: > Hi Alexander, > it seems to me that RXTX is implementing this API: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Kind regards, > Eike > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kjetilos at gmail.com Fri Sep 4 03:43:41 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 11:43:41 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> Message-ID: <7a803d460909040243ke4449ecucbe2cd8b15761746@mail.gmail.com> Hi Daniel, This is interesting, what type of application are you making? Is there a lot of signaling on different COM ports at the same time in your application? In our application we have 11 devices connected to different COM ports, 9 of these are in active use when the application is running. I'm wondering how to use the RXTX library version 2.1.7 in this scenario without causing it to crash. After adding more signaling on the COM ports in our application we have now experienced other crashes and it is natural to think that it has something to do with our way of using RXTX from several threads at the same time. So my question is are there any methods like read/write/flush/close that are not thread safe and should be handled with care? And similarly is the RXTXPort.SerialInputStream and RXTXPort.SerialOutputStream thread safe? 2009/9/3 Daniel Morton : > I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. ?(I haven't tried previous version though). > > Daniel Morton > Java/J2EE Developer > > Tel ? ?+1 519.745.8887 x4331 > Email ? ?dmorton at intellimec.com > > > www.intellimec.com ?| ?www.iLane.com ?| ?www.drivesync.com > > > > Intelligent Mechatronic Systems Inc. > 435 King Street North Waterloo, ON N2J 2Z5 > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s > Sent: Thursday, September 03, 2009 4:50 AM > To: rxtx at qbang.org > Subject: [Rxtx] RXTX multiple crashes > > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x7d0d] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0ce75800): ?JavaThread "Y Worker" daemon > [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 > > Registers: > EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 > ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 > EIP=0x10007d0d, EFLAGS=0x00010202 > > Top of Stack: (sp=0x0d7ff6d8) > 0x0d7ff6d8: ? 0d7ff700 00000000 00000000 00000000 > 0x0d7ff6e8: ? 02a2eae8 00000123 00002958 0d7ff718 > 0x0d7ff6f8: ? 7c830887 7c90d28a 7c8664b5 00000e2c > 0x0d7ff708: ? 00002958 00000000 00000000 7c90cffa > 0x0d7ff718: ? 7c809bdb 00002958 0d7ff758 00000e40 > 0x0d7ff728: ? 00002958 02bd0468 0ce75800 080e4ee0 > 0x0d7ff738: ? 00000000 00000000 00000000 00000000 > 0x0d7ff748: ? 00000000 00000000 00000014 7c90d09a > > Instructions: (pc=0x10007d0d) > 0x10007cfd: ? 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 > 0x10007d0d: ? 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 > > > Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x7d0d] > J ?gnu.io.RXTXPort.nativeDrain(Z)Z > J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > ... > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x9c55] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0cddf400): ?JavaThread "XXX Worker" daemon > [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 > > Registers: > EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 > ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 > EIP=0x10009c55, EFLAGS=0x00010206 > > Top of Stack: (sp=0x0bb8f830) > 0x0bb8f830: ? 00000000 00000000 c0000005 00000000 > 0x0bb8f840: ? 00000000 00f1f0a5 00000002 00000000 > 0x0bb8f850: ? 003a0100 0001003f 0bb8fb20 0b9ff918 > 0x0bb8f860: ? 00000000 00000000 0bb8fb68 0bb8fb20 > 0x0bb8f870: ? 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 > 0x0bb8f880: ? 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 > 0x0bb8f890: ? 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 > 0x0bb8f8a0: ? 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 > > Instructions: (pc=0x10009c55) > 0x10009c45: ? 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff > 0x10009c55: ? 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 > > > Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x9c55] > C ?[rxtxSerial.dll+0xa05e] > J ?gnu.io.RXTXPort.readByte()I > J ?gnu.io.RXTXPort$SerialInputStream.read()I > J ?java.io.FilterInputStream.read()I > ... > > -- > Kjetil ?ster?s > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kjetil ?ster?s From tjarvi at qbang.org Fri Sep 4 06:00:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Sep 2009 06:00:40 -0600 (MDT) Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x7d0d] > J gnu.io.RXTXPort.nativeDrain(Z)Z > J gnu.io.RXTXPort$SerialOutputStream.flush()V > Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x9c55] > C [rxtxSerial.dll+0xa05e] > J gnu.io.RXTXPort.readByte()I > J gnu.io.RXTXPort$SerialInputStream.read()I RXTX 2.1-7 has concurrency issues that will show upon multicore systems. These should be resolved in the 2.2 pre release. A user application could synchronize the read/write/open/close calls while using 2.1 to avoid the concurrency issue. The flush is probably following a write while the readByte is coming from read(byte b). The bugs existed in rxtx for a long time. I assume changes in the JVM and the presence of multicore systems exposed the issues. -- Trent Jarvi tjarvi at qbang.org From kjetilos at gmail.com Fri Sep 4 06:33:33 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 14:33:33 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <7a803d460909040533n1caf240y8168477a578bc45c@mail.gmail.com> Den 4. september 2009 14.00 skrev Trent Jarvi f?lgende: > > > On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > >> Hi >> >> We are using RXTX version 2.1.7 actively and lately we are having some >> issues with the RXTX library crashing. We are running a windows xp >> system with multiple COM ports where each COM port have a serial >> device connected. Lately we have increased the amount of signaling >> done over the COM ports and we are experiencing several odd crashes. I >> tried to search the mailinglist for something similar but was unable >> to find anything. At one time the RXTX crashed in the >> gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the >> gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack >> traces if someone is interested in having a look. Has anyone seen the >> same crashes? and does anyone know what can cause such crash? >> >> >> Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x7d0d] >> J ?gnu.io.RXTXPort.nativeDrain(Z)Z >> J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > >> Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x9c55] >> C ?[rxtxSerial.dll+0xa05e] >> J ?gnu.io.RXTXPort.readByte()I >> J ?gnu.io.RXTXPort$SerialInputStream.read()I > > > RXTX 2.1-7 has concurrency issues that will show upon multicore systems. > These should be resolved in the 2.2 pre release. ?A user application could > synchronize the read/write/open/close calls while using 2.1 to avoid the > concurrency issue. > > The flush is probably following a write while the readByte is coming from > read(byte b). > > The bugs existed in rxtx for a long time. ?I assume changes in the JVM and > the presence of multicore systems exposed the issues. > Ok, so we should look more into using a newer version of RXTX. The current version from the webpage is 2.2pre2, what is the stability status of this version. Is it good enough for use in a production environment? -- Kjetil ?ster?s From martinezrodolfo at gmail.com Fri Sep 4 13:39:57 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Fri, 4 Sep 2009 15:09:57 -0430 Subject: [Rxtx] Problem with data available event Message-ID: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Hello list members. I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a serial port USB adapter to communicate with an electronical inmunoassay analyzer. The program works porperly with one model of the analyzer series. It defines a protocol which every message sent should be replied with an ACK in order to continue with the communication. Now we are trying to communicate with another model of the same brand and series wich in theory should be much of the same of what was previously done. Unfortunately, that is not the case. The problem with this connection is that it never fires the Data Available serial port event. Is like if nothing was being received in the input stream. The following code always prints zero when the equipment should be transmitting. ----------------------- beginning of sample code ---------------------------------- SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", 10000); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); int len = 0; byte[] readBuffer = new byte[8]; while (true) { len = in.read(readBuffer); System.out.println(len); writer.writeACK(); // writing ACK to analyzer } ----------------------- end of sample code ------------------------------------------ We know that the analyzer is transmitting because HyperTerminal does shows the proper output. In fact, after running the above code and connecting via Hyperterminal all data is received in one block. Is like the data sent from the analyzer is being held somewhere in the way. Sniffing at the serial port, noticed that IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this helps to find what might be wrong or not, but here they are: On Hyperterminal: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 XonLimit:80 XoffLimit:200 On Java: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 XonLimit:0 XoffLimit:0 Thanks in advance for your help. Rodolfo M From ilkka at myller.com Sat Sep 5 04:36:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 5 Sep 2009 13:36:27 +0300 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <121198EE-65A4-463B-ACC7-29FFB9855B2C@myller.com> Hi Rodolfo, By default RXTX does not enable any flow control for the serial port. Please check what flow control you have active in HyperTerminal when you are able to receive data and then use the same flow control with RXTX serial port: serialPort.setFlowControlMode(int flowcontrol); Possible flowcontrol flags are (from SerialPort class) FLOWCONTROL_NONE FLOWCONTROL_RTSCTS_IN FLOWCONTROL_RTSCTS_OUT FLOWCONTROL_XONXOFF_IN FLOWCONTROL_XONXOFF_OUT For example, you can try enabling RTS/CTS hardware flow control. Note the bitwise OR operator ' | ': serialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Also if your device requires RTS/CTS flow control make sure you have fully connected serial cable (not just RX, TX, GND for example, but also RTS, CTS, DTR). One thing you might want to check is the state of DTR (Data Terminal Ready). Some devices wait for the DTR signal before they send any data. You can enable or disable DTR signal (high/low) with: serialPort.setDTR( boolean state ); -- I > Hello list members. > > I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a > serial port USB adapter to communicate with an electronical > inmunoassay analyzer. The program works porperly with one model of the > analyzer series. It defines a protocol which every message sent should > be replied with an ACK in order to continue with the communication. > Now we are trying to communicate with another model of the same brand > and series wich in theory should be much of the same of what was > previously done. Unfortunately, that is not the case. The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. > > ----------------------- beginning of sample code > ---------------------------------- > SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", > 10000); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > InputStream in = serialPort.getInputStream(); > OutputStream out = serialPort.getOutputStream(); > > int len = 0; > byte[] readBuffer = new byte[8]; > while (true) { > len = in.read(readBuffer); > System.out.println(len); > > writer.writeACK(); // writing ACK to analyzer > } > ----------------------- end of sample code > ------------------------------------------ > > We know that the analyzer is transmitting because HyperTerminal does > shows the proper output. In fact, after running the above code and > connecting via Hyperterminal all data is received in one block. Is > like the data sent from the analyzer is being held somewhere in the > way. Sniffing at the serial port, noticed that > IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this > helps to find what might be wrong or not, but here they are: > > On Hyperterminal: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 > XonLimit:80 XoffLimit:200 > > On Java: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 > XonLimit:0 XoffLimit:0 > > > Thanks in advance for your help. > Rodolfo M > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.weber99 at gmx.net Sun Sep 6 13:51:12 2009 From: karl.weber99 at gmx.net (Karl Weber) Date: Sun, 6 Sep 2009 21:51:12 +0200 Subject: [Rxtx] Cannot create lock file Message-ID: <200909062151.12228.karl.weber99@gmx.net> Hi, I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an opensuse repository as well as from the homepage of the rxtx project. I have already added the user to the group uucp, however, it does not have any effect. What else do I have to do to make it work? (It does work with user root, though.) The error message is: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL Thanks in advance, Karl From tjarvi at qbang.org Sun Sep 6 13:51:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 6 Sep 2009 13:51:42 -0600 (MDT) Subject: [Rxtx] Cannot create lock file In-Reply-To: <200909062151.12228.karl.weber99@gmx.net> References: <200909062151.12228.karl.weber99@gmx.net> Message-ID: On Sun, 6 Sep 2009, Karl Weber wrote: > Hi, > > I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an > opensuse repository as well as from the homepage of the rxtx project. > > I have already added the user to the group uucp, however, it does not have > any effect. What else do I have to do to make it work? (It does work with > user root, though.) > > The error message is: > > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to > create lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > > Thanks in advance, Karl Look at the group that owns /var/lock with ls -ld /var/lock The following should work as a user when they are in the correct group: touch /var/lock/test && rm -f /var/lock/test -- Trent Jarvi tjarvi at qbang.org From Luca.Catoni at sysdat.it Mon Sep 7 06:32:42 2009 From: Luca.Catoni at sysdat.it (Luca Catoni) Date: Mon, 7 Sep 2009 14:32:42 +0200 Subject: [Rxtx] time-out implementation Message-ID: I need to implement a simple timer class to manage time-out in my RS-232 serial communication with a remote device using the rxtx library. The functions that the timer should have are start(), and reset() and start() method must throw an exception (TimeoutException) when it expires. I am not an expert in concurrent programming and I do not have much knowledge on threads. myTimer.setExpirationTime(myvalue); ? public void serialEvent(SerialPortEvent event) { if (event.getEventType() == SerialPortEvent.OUTPUT_BUFFER_EMPTY) { // transmission ? out.write(?); try{ myTimer.start(); }catch(TimeoutException te){ myTimer.reset(); ? } ? if (event.getEventType() == SerialPortEvent.DATA_AVAILABLE) { // receiving in.read(?); if (mycondition){ myTimer.stop();//ok, timer NOT expired myTimer.reset();//now I can call start() method again in //transmission to restart my timer when I //have to transmit next data } Can anyone help me to implement the class MyTimer? thanks in advance. -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Mon Sep 7 06:49:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Mon, 7 Sep 2009 18:19:24 +0530 Subject: [Rxtx] 2.2Pre + MacMini+ Deadlock while second time port Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E22FB6F@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, Please find the updated code (close call was commented by mistake). This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From michael.erskine at ketech.com Mon Sep 7 09:13:03 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 7 Sep 2009 16:13:03 +0100 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Rodolfo Mart?nez > Subject: [Rxtx] Problem with data available event > The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. Hi Rodolfo, The sample code you provided doesn't implement or register any event listeners. Regards, Michael Erskine. From martinezrodolfo at gmail.com Mon Sep 7 10:21:22 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Mon, 7 Sep 2009 11:51:22 -0430 Subject: [Rxtx] Problem with data available event In-Reply-To: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> Message-ID: <30eacee0909070921l7f285765ue2c661963183fd2b@mail.gmail.com> On Mon, Sep 7, 2009 at 10:43 AM, Michael Erskine wrote: > Hi Rodolfo, > The sample code you provided doesn't implement or register any event listeners. > > Regards, > Michael Erskine. Hi Michael, I didn't write the event listeners declaration on the sample code for simplicity, but I do implement them on my real code. I should have mentioned it on the sample code anyway... my bad. I haven't had access to the device I'm trying to connect, but tomorrow will. And hope that with the explanation of Ilkka Myller will succeed this time. Thanks for your attention. Rodolfo M From ajmas at sympatico.ca Mon Sep 7 16:58:13 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 7 Sep 2009 18:58:13 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" I noticed in the page you posted posted you indicated that you patched two files. Did you submit the changes to Jarvi, so they could be included in the main code branch? Andr? From tjarvi at qbang.org Mon Sep 7 16:57:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Sep 2009 16:57:53 -0600 (MDT) Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On Mon, 7 Sep 2009, Andre-John Mas wrote: > > On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > >> Sorry, my rudeness was not intentional (a typo). >> Lets try again.. ;) >> >> "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > I noticed in the page you posted posted you indicated that you patched two > files. Did you submit the changes to Jarvi, so they could be included in the > main code branch? > Hi Andr? Ilkka is working with us to get changes in. I'm not sure about those two patches which may already be in CVS. I'll let him answer that. I've given him write access to CVS and asked him to cc the list non whitespace changes when they are ready. Right now he is asking questions off the list regarding cleaning up the Mac and w32 build files. -- Trent Jarvi tjarvi at qbang.org From nsp25 at cornell.edu Mon Sep 7 21:17:45 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Mon, 7 Sep 2009 23:17:45 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: (Sorry if this is a double post, but I sent my original message without subscribing, and since this is an urgent problem, I thought I'd resend after subscribing to bypass the moderator limbo zone) Hi all, I've asked my question on StackOverflow already, so rather than copy-paste the question here, I'd like to redirect you there . Short version, I am no longer able to receive anything over RS-232 with RXTX, but other programs work fine. I'm definitely sending things, because when I connect with a different program, all the responses to the commands I sent via RXTX arrive all at once. Everything was fine in the spring, so what could have happened? Windows update? -Nate -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.j.tandy at warwick.ac.uk Tue Sep 8 01:30:48 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Tue, 8 Sep 2009 08:30:48 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> OK, so: 1. It worked in spring but has stopped doing so and 2. The data all arrives at once when you start hyperterminal. Is it possible you're using a different serial cable to connect to the device, compared to the one you were using in spring? If so, the issue might be hardware flow control - that is, your device might be buffering data because it can't transmit it until your computer sets 'DTR' or 'RTS' or something like that. One way of bypassing hardware flow control is by using cables which cross over certain wires so that the right signals are always being sent; it's possible your old cable had these connections but your current cable doesn't have them. If you can find the old cable, you could put it back in and see if that fixes things? 2009/9/8 Nathaniel S. Parsons : > (Sorry if this is a double post, but I sent my original message without > subscribing, and since this is an urgent problem, I thought I'd resend after > subscribing to bypass the moderator limbo zone) > > Hi all, > > I've asked my question on StackOverflow already, so rather than copy-paste > the question here, I'd like to redirect you there. > > Short version, I am no longer able to receive anything over RS-232 with > RXTX, but other programs work fine. I'm definitely sending things, because > when I connect with a different program, all the responses to the commands I > sent via RXTX arrive all at once. > > Everything was fine in the spring, so what could have happened? Windows > update? > > -Nate > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Tue Sep 8 01:50:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 8 Sep 2009 10:50:33 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <111FEC9A-26BA-435C-BABC-314C7E4F23E5@myller.com> Hi all, Patches applied to the 2.1.7 binaries distributed by Robert Harder (http://iharder.sourceforge.net/current/java/ ) are already in the 2.2. Actually in 2.2 the issue with integer types handling seems to be fixed even more extensively than that single patch to 2.1.7 originally did. And yes, Trent has granted me CVS commit access. Thank you. First thing I'm going to focus on is the code quality and clean up: unused variables, invalid pointer usage etc.. Most of this just causing compile warnings - some harmless and some have potential for causing runtime problems. Instead of just blindly committing new changes to CVS, I've been discussing with Trent about the way things have been done in the RXTX CVS before. (how to handle white space patches, what needs to be discussed with the list first, proper locations for new files/ directories/subprojects, "the way things are done in RXTX"). But patches are coming and bugs will be fixed. I hope everyone will continue to submit the bugs they discover to this mailing list. Most important thing is to provide enough info (code;) so that the issue can be duplicated and eventually fixed. -- I > > > On Mon, 7 Sep 2009, Andre-John Mas wrote: >> >> I noticed in the page you posted posted you indicated that you >> patched two files. Did you submit the changes to Jarvi, so they >> could be included in the main code branch? >> > > Ilkka is working with us to get changes in. I'm not sure about > those two patches which may already be in CVS. I'll let him answer > that. > > I've given him write access to CVS and asked him to cc the list non > whitespace changes when they are ready. Right now he is asking > questions off the list regarding cleaning up the Mac and w32 build > files. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 15:35:19 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 17:35:19 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: Thanks for the response. I'll try to get to the electronics store tomorrow to get more serial cables, even if it isn't the problem. I am using a different serial cable than I was in the spring. It's actually a Male/Female cable with a female-female adapter since the old cables aren't around anymore. The hardware's manual says nothing except to use a "Straight cable" but I figured that if it worked in HyperTerminal, it should work in RXTX, right? Anyways, I've also noticed some things that are different between HyperTerminal, RXTX, and a separate program I found that communicates with the device (but doesn't do what I want, which is why I'm rolling my own program) HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and DTR indicators are green Other program - not sure what settings it thinks it's using, but only SPM's RTS indicator is green RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators are on. >From Serial Port Monitor's help files (paraphrased): the indicators display the state of the serial control lines RTS - Request To Send CTS - Clear To Send DTR - Data Terminal Ready Could this be related to the problem? -Nate On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > OK, so: > > 1. It worked in spring but has stopped doing so and > 2. The data all arrives at once when you start hyperterminal. > > Is it possible you're using a different serial cable to connect to the > device, compared to the one you were using in spring? > > If so, the issue might be hardware flow control - that is, your device > might be buffering data because it can't transmit it until your > computer sets 'DTR' or 'RTS' or something like that. > > One way of bypassing hardware flow control is by using cables which > cross over certain wires so that the right signals are always being > sent; it's possible your old cable had these connections but your > current cable doesn't have them. If you can find the old cable, you > could put it back in and see if that fixes things? > > > 2009/9/8 Nathaniel S. Parsons : > > (Sorry if this is a double post, but I sent my original message without > > subscribing, and since this is an urgent problem, I thought I'd resend > after > > subscribing to bypass the moderator limbo zone) > > > > Hi all, > > > > I've asked my question on StackOverflow already, so rather than > copy-paste > > the question here, I'd like to redirect you there. > > > > Short version, I am no longer able to receive anything over RS-232 with > > RXTX, but other programs work fine. I'm definitely sending things, > because > > when I connect with a different program, all the responses to the > commands I > > sent via RXTX arrive all at once. > > > > Everything was fine in the spring, so what could have happened? Windows > > update? > > > > -Nate > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 18:57:58 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 20:57:58 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: I added a call to setRTS() but nothing changed in Serial Port Monitor, no matter what the argument was. Is this a bug, or did I call the wrong function? I tried to find the c code behind this function, and I think I found it in rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong to me. Am I looking at the right function or is the problem somewhere else? -Nate On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons wrote: > Thanks for the response. I'll try to get to the electronics store tomorrow > to get more serial cables, even if it isn't the problem. > > I am using a different serial cable than I was in the spring. It's actually > a Male/Female cable with a female-female adapter since the old cables aren't > around anymore. The hardware's manual says nothing except to use a "Straight > cable" but I figured that if it worked in HyperTerminal, it should work in > RXTX, right? > > Anyways, I've also noticed some things that are different between > HyperTerminal, RXTX, and a separate program I found that communicates with > the device (but doesn't do what I want, which is why I'm rolling my own > program) > > HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and > DTR indicators are green > Other program - not sure what settings it thinks it's using, but only SPM's > RTS indicator is green > RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators > are on. > > From Serial Port Monitor's help files (paraphrased): the indicators display > the state of the serial control lines > > RTS - Request To Send > CTS - Clear To Send > DTR - Data Terminal Ready > > Could this be related to the problem? > > -Nate > > > On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > >> OK, so: >> >> 1. It worked in spring but has stopped doing so and >> 2. The data all arrives at once when you start hyperterminal. >> >> Is it possible you're using a different serial cable to connect to the >> device, compared to the one you were using in spring? >> >> If so, the issue might be hardware flow control - that is, your device >> might be buffering data because it can't transmit it until your >> computer sets 'DTR' or 'RTS' or something like that. >> >> One way of bypassing hardware flow control is by using cables which >> cross over certain wires so that the right signals are always being >> sent; it's possible your old cable had these connections but your >> current cable doesn't have them. If you can find the old cable, you >> could put it back in and see if that fixes things? >> >> >> 2009/9/8 Nathaniel S. Parsons : >> > (Sorry if this is a double post, but I sent my original message without >> > subscribing, and since this is an urgent problem, I thought I'd resend >> after >> > subscribing to bypass the moderator limbo zone) >> > >> > Hi all, >> > >> > I've asked my question on StackOverflow already, so rather than >> copy-paste >> > the question here, I'd like to redirect you there. >> > >> > Short version, I am no longer able to receive anything over RS-232 with >> > RXTX, but other programs work fine. I'm definitely sending things, >> because >> > when I connect with a different program, all the responses to the >> commands I >> > sent via RXTX arrive all at once. >> > >> > Everything was fine in the spring, so what could have happened? Windows >> > update? >> > >> > -Nate >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Tue Sep 8 21:54:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 21:54:26 -0600 (MDT) Subject: [Rxtx] rxtx is moving to the clouds Message-ID: rxtx is moving onto a cloud server. You may notice short outages as things move around. So far the following is done. http://rxtx.qbang.org (will redirect rxtx.org there for 2.2) http://bugzilla.qbang.org (bugs) The mail-list is tomorrow night. CVS and FTP will be last. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 8 22:03:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 22:03:26 -0600 (MDT) Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: On Tue, 8 Sep 2009, Nathaniel S. Parsons wrote: > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? Hi Nathaniel, That depends upon what you are running. WinCE is for embedded windows. The Windows source is in src/termios.c (called from src/SerialImp.c). -- Trent Jarvi tjarvi at qbang.org From m.j.tandy at warwick.ac.uk Wed Sep 9 03:27:10 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 10:27:10 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> I had a similar problem a while ago - hardware that would work with Hyperterminal but not with Rxtx. I don't know if this is a bug in RxTx or not - I tried to find where in the RxTx source code those functions are actually implemented - I got as far as the ioctl function in termios.c, where the TIOCMSET case sets the MSR byte in the termios struct, but I can't figure out where that gets written to the dcb struct's fDtrControl dword. It could be a bug, or it could just be me missing something. In any case, at the time I had this problem I wasn't equipped to debug RxTx so instead I created a special cable to satisfy the hardware's flow control while leaving the data connection straight through. Here's how I connected it: At the female end of the cable (i.e. the hardware I was connecting to) I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. I connected the ground and data pins straight through - that is, pin 5 female end to pin 5 male end, pin 2 female end to pin 2 male end, pin 3 female end to pin 3 male end. Anyway, using that cable bypassed the hardware's flow control, and got RxTx working just as well as HyperTerminal - although I slowed down my communication to make sure I didn't encounter a situation where the flow control would have come into effect, as I had bypassed it! Hope that helps. 2009/9/9 Nathaniel S. Parsons : > I added a call to setRTS() but nothing changed in Serial Port Monitor, no > matter what the argument was. Is this a bug, or did I call the wrong > function? > > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? > > -Nate > > On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > wrote: >> >> Thanks for the response. I'll try to get to the electronics store tomorrow >> to get more serial cables, even if it isn't the problem. >> >> I am using a different serial cable than I was in the spring. It's >> actually a Male/Female cable with a female-female adapter since the old >> cables aren't around anymore. The hardware's manual says nothing except to >> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >> should work in RXTX, right? >> >> Anyways, I've also noticed some things that are different between >> HyperTerminal, RXTX, and a separate program I found that communicates with >> the device (but doesn't do what I want, which is why I'm rolling my own >> program) >> >> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >> DTR indicators are green >> Other program - not sure what settings it thinks it's using, but only >> SPM's RTS indicator is green >> RXTX - no matter what flow control I set, only SPM's CTS and DTR >> indicators are on. >> >> From Serial Port Monitor's help files (paraphrased): the indicators >> display the state of the serial control lines >> >> RTS - Request To Send >> CTS - Clear To Send >> DTR - Data Terminal Ready >> >> Could this be related to the problem? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> wrote: >>> >>> OK, so: >>> >>> 1. It worked in spring but has stopped doing so and >>> 2. The data all arrives at once when you start hyperterminal. >>> >>> Is it possible you're using a different serial cable to connect to the >>> device, compared to the one you were using in spring? >>> >>> If so, the issue might be hardware flow control - that is, your device >>> might be buffering data because it can't transmit it until your >>> computer sets 'DTR' or 'RTS' or something like that. >>> >>> One way of bypassing hardware flow control is by using cables which >>> cross over certain wires so that the right signals are always being >>> sent; it's possible your old cable had these connections but your >>> current cable doesn't have them. If you can find the old cable, you >>> could put it back in and see if that fixes things? >>> >>> >>> 2009/9/8 Nathaniel S. Parsons : >>> > (Sorry if this is a double post, but I sent my original message without >>> > subscribing, and since this is an urgent problem, I thought I'd resend >>> > after >>> > subscribing to bypass the moderator limbo zone) >>> > >>> > Hi all, >>> > >>> > I've asked my question on StackOverflow already, so rather than >>> > copy-paste >>> > the question here, I'd like to redirect you there. >>> > >>> > Short version, I am no longer able to receive anything over RS-232 with >>> > RXTX, but other programs work fine. I'm definitely sending things, >>> > because >>> > when I connect with a different program, all the responses to the >>> > commands I >>> > sent via RXTX arrive all at once. >>> > >>> > Everything was fine in the spring, so what could have happened? Windows >>> > update? >>> > >>> > -Nate >>> > >>> > _______________________________________________ >>> > Rxtx mailing list >>> > Rxtx at qbang.org >>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>> > >>> > >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Wed Sep 9 03:54:45 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 12:54:45 +0300 Subject: [Rxtx] Xcode 3.x project available in CVS Message-ID: Hi everyone, I've just committed Apple Xcode 3.x (preferably 3.2) compatible project to CVS. The project can be used to develop and build Mac OS X 10.5+ compatible Universal Binary JNI library and RXTXcomm.jar. It's does not have dependencies to existing Autotools based build scripts - only standard Xcode installation is required. The older Xcode 2.x project is still there, but please note that it's not compatible with newer Xcode versions due to its dependency to deprecated Jam build system. The new project is available in rxtx-devel/MACOSX_IDE/Xcode3 How to get the source code from CVS: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Latest Xcode can be downloaded from Apple: http://developer.apple.com/technology/xcode.html -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 05:07:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 14:07:05 +0300 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: Nathaniel, I agree with Michael that your issue is probably with incorrect hardware flow control (RTS/CTS + possibly DTR/DSR). With RXTX you can do things manually, automatically or by mixing both ways. RXTX is "low-level" enough to let developer make those decisions. Which is proper. Automatic hardware flow-control: If you want to do automatic RTS/CTS flow control in both directions (from and to PC) you must set: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Note that you must combine flow control flags with bitwise OR ( ' | ' ) Manual: If you want to bypass all flow controls signals, or handle them manually you must set: setFlowControlMode( SerialPort.FLOWCONTROL_NONE ); In manual mode, you must manually handle controlling signals from PC and reading flow control signals from by the device: RTS - Request To Send -- setRTS() method can used to set this CTS - Clear To Send -- isCTS() method can be used to read this For example, it is entirely possible to manually implement normal RTS/ CTS flow control with RXTX without relying on low-level automatic implementation. Mixed: You can also configure serial port to handle RTS/CTS automatically in only one direction, then you must set one of: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN ); or setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_OUT ); Then you can either ignore or implement manually the flow control scheme in the other direction. DTR and DSR: These are not officially flow control signals, but might affect external devices (disable, standby etc.). Use and meaning of these depends on the device. DTR - Data Terminal Ready -- setDTR() method DSR - Data Set Ready -- setDSR() method CTS/RTS standards: Please note that there are two standard ways RTS/CTS flow control is done (depends on the device): asymmetric (RS-232) symmetric (RS-232-E / TIA-232-E) For more info see: http://en.wikipedia.org/wiki/RS232#RTS.2FCTS_handshaking Some devices may even use RTS/CTS to some other non-standard purpose. With those devices, enabling automatic RTS/CTS could cause very strange behaviour as they clearly require manual control of CTS/RTS. ---- As far as I know, RXTX properly controls all these signals all the way to actual RS232 pins - unless there is a new platform incompatibility bug that I'm not aware of;) Mostly it's just wrong combination and/or usage of these additional signals that cause problems receiving or sending. And the only solution is to really *know* how your device wants these signals handled - and then code your RXTX application accordingly. Creating non-standard cable is not the right solution in my opinion. Unfortunately some applications (like HyperTerminal for example) might hit more or less accidentally to the right combination of RTS/CTS/DTR/ DSR usage and make RXTX look bad in comparison. While all RXTX does by default is - well - nothing. It gives full control the developer. -- I > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port >> Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I >> found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't >> look wrong >> to me. Am I looking at the right function or is the problem >> somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > > >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store >>> tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since >>> the old >>> cables aren't around anymore. The hardware's manual says nothing >>> except to >>> use a "Straight cable" but I figured that if it worked in >>> HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that >>> communicates with >>> the device (but doesn't do what I want, which is why I'm rolling >>> my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's >>> RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but >>> only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> > >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect >>>> to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your >>>> device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>>> (Sorry if this is a double post, but I sent my original message >>>>> without >>>>> subscribing, and since this is an urgent problem, I thought I'd >>>>> resend >>>>> after >>>>> subscribing to bypass the moderator limbo zone) >>>>> >>>>> Hi all, >>>>> >>>>> I've asked my question on StackOverflow already, so rather than >>>>> copy-paste >>>>> the question here, I'd like to redirect you there. >>>>> >>>>> Short version, I am no longer able to receive anything over >>>>> RS-232 with >>>>> RXTX, but other programs work fine. I'm definitely sending things, >>>>> because >>>>> when I connect with a different program, all the responses to the >>>>> commands I >>>>> sent via RXTX arrive all at once. >>>>> >>>>> Everything was fine in the spring, so what could have happened? >>>>> Windows >>>>> update? >>>>> >>>>> -Nate >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 06:11:11 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 15:11:11 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings Message-ID: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Hi, Summary: Patch includes multiple minor code quality improvements and also fixes one possible null pointer segfault on Mac. After this patch, compilation on Mac OS X is error/warning free even with gcc -Wall setting. I'll submit more code quality patches later that focus more on linux/ win/java. Fixes: Code quality: - First level parentheses around assignment used as while-loop truth value - Some printf formats not a string literals and including no format arguments Invalid null pointer usage: - Mac: IOMasterPort was called with (int)NULL which does not always resolve to segfault safe value. Corrected to use MACH_PORT_NULL instead. Patch: The patch is against CVS head (@2009/09/09). Attached patch file is in 'cvs diff -up' format. I'll commit this patch to the CVS later this week if there are no objections. Feel free to comment. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090909.patch Type: application/octet-stream Size: 1966 bytes Desc: not available URL: From m.j.tandy at warwick.ac.uk Wed Sep 9 06:57:55 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 13:57:55 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> OK, I just ran a test with my copy of RxTx and the following program: import gnu.io.*; public class SerialTest { public static void main(String[] args) { try { CommPortIdentifier portid = CommPortIdentifier.getPortIdentifier("COM9"); SerialPort serialPort = (SerialPort)portid.open("Serial port DTR/RTS test", 1000); serialPort.setSerialPortParams(4800, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.disableReceiveTimeout(); for (int i=0 ; i<60 ; i++) { serialPort.setDTR(true); serialPort.setRTS(true); Thread.sleep(1000); serialPort.setDTR(false); serialPort.setRTS(false); Thread.sleep(1000); } } catch (Exception e) { e.printStackTrace(); System.exit(1); } System.exit(0); } } I'm using a USB-serial converter (Prolific PL-2303) and I used a multimeter to check that my DTR and RTS pins were both toggling, and they were - between +7 and -6.4 volts. In other words, on the computer I'm using at the moment, with the version of RxTx I'm using at the moment, setDTR and setRTS both seem to work fine. I don't know if it's worth it for you to perform the same test. I gather there are several different configurations for hardware flow control, (DTR/DSR handshaking as well as RTS/CTS handshaking, handshaking for half-duplex operation, and similar) so the cable that worked for me might still be worth a try. 2009/9/9 Michael Tandy : > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong >> to me. Am I looking at the right function or is the problem somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since the old >>> cables aren't around anymore. The hardware's manual says nothing except to >>> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that communicates with >>> the device (but doesn't do what I want, which is why I'm rolling my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>> > (Sorry if this is a double post, but I sent my original message without >>>> > subscribing, and since this is an urgent problem, I thought I'd resend >>>> > after >>>> > subscribing to bypass the moderator limbo zone) >>>> > >>>> > Hi all, >>>> > >>>> > I've asked my question on StackOverflow already, so rather than >>>> > copy-paste >>>> > the question here, I'd like to redirect you there. >>>> > >>>> > Short version, I am no longer able to receive anything over RS-232 with >>>> > RXTX, but other programs work fine. I'm definitely sending things, >>>> > because >>>> > when I connect with a different program, all the responses to the >>>> > commands I >>>> > sent via RXTX arrive all at once. >>>> > >>>> > Everything was fine in the spring, so what could have happened? Windows >>>> > update? >>>> > >>>> > -Nate >>>> > >>>> > _______________________________________________ >>>> > Rxtx mailing list >>>> > Rxtx at qbang.org >>>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>>> > >>>> > >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > From david at attglobal.net Wed Sep 9 09:17:27 2009 From: david at attglobal.net (David Schmidt) Date: Wed, 09 Sep 2009 11:17:27 -0400 Subject: [Rxtx] 2.2 Release plans Message-ID: <4AA7C707.5060802@attglobal.net> I'm holding off releasing an update to my project (adtpro.sourceforge.net) to support OSX Snow Leopard because I'd like to ship an "official" build of rxtx 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for toggling a port off). CVS is looking great on OSX - thanks to all who have been hard at work on that. I wish there were just one more update - Pre3? :-) My question... If I wanted to make a release in, say, a week... would it pay to wait for rxtx, or should I plan to build and ship a local build of 2.2 out of CVS myself? - David Schmidt From tjarvi at qbang.org Wed Sep 9 19:14:29 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:14:29 -0600 (MDT) Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: On Wed, 9 Sep 2009, Ilkka Myller wrote: > Hi, > > Summary: > > Patch includes multiple minor code quality improvements and also fixes one > possible null pointer segfault on Mac. > After this patch, compilation on Mac OS X is error/warning free even with gcc > -Wall setting. > I'll submit more code quality patches later that focus more on > linux/win/java. > > Fixes: > > Code quality: > - First level parentheses around assignment used as while-loop truth value > - Some printf formats not a string literals and including no format arguments > > Invalid null pointer usage: > - Mac: IOMasterPort was called with (int)NULL which does not always resolve > to segfault safe value. Corrected to use MACH_PORT_NULL instead. > > Patch: > > The patch is against CVS head (@2009/09/09). > Attached patch file is in 'cvs diff -up' format. > > I'll commit this patch to the CVS later this week if there are no objections. > Feel free to comment. > These ifdefs can go. If you like I can remove them when you are done. #ifdef DEBUG_MW mexErrMsgTxt( msg ); #else They are just printf like debug messages for use in an environment in which I could not get directly to stderr/stdout. I don't think anyone uses them anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Sep 9 19:17:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:17:43 -0600 (MDT) Subject: [Rxtx] 2.2 Release plans In-Reply-To: <4AA7C707.5060802@attglobal.net> References: <4AA7C707.5060802@attglobal.net> Message-ID: On Wed, 9 Sep 2009, David Schmidt wrote: > I'm holding off releasing an update to my project (adtpro.sourceforge.net) to > support OSX Snow Leopard because I'd like to ship an "official" build of rxtx > 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for > toggling a port off). CVS is looking great on OSX - thanks to all who have > been hard at work on that. I wish there were just one more update - Pre3? > :-) > > My question... If I wanted to make a release in, say, a week... would it pay > to wait for rxtx, or should I plan to build and ship a local build of 2.2 out > of CVS myself? > Hi David, I would suggest planning on shipping a local build in a 1 week timeframe. We could put another prerelease up but there are still fixes coming in. -- Trent Jarvi tjarvi at qbang.org From ilkka at myller.com Wed Sep 9 23:07:34 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:07:34 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: <04A41559-598C-4B6E-821A-DA90CB6228E7@myller.com> Patch (im-20090909.patch) has been committed to the CVS. Trent: I'll include DEBUG_MW cleanup to my next patch. > > On Wed, 9 Sep 2009, Ilkka Myller wrote: > >> Hi, >> >> Summary: >> >> Patch includes multiple minor code quality improvements and also >> fixes one possible null pointer segfault on Mac. >> After this patch, compilation on Mac OS X is error/warning free >> even with gcc -Wall setting. >> I'll submit more code quality patches later that focus more on >> linux/win/java. >> >> Fixes: >> >> Code quality: >> - First level parentheses around assignment used as while-loop >> truth value >> - Some printf formats not a string literals and including no format >> arguments >> >> Invalid null pointer usage: >> - Mac: IOMasterPort was called with (int)NULL which does not always >> resolve to segfault safe value. Corrected to use MACH_PORT_NULL >> instead. >> >> Patch: >> >> The patch is against CVS head (@2009/09/09). >> Attached patch file is in 'cvs diff -up' format. >> >> I'll commit this patch to the CVS later this week if there are no >> objections. >> Feel free to comment. >> > > These ifdefs can go. If you like I can remove them when you are done. > > #ifdef DEBUG_MW > mexErrMsgTxt( msg ); > #else > > They are just printf like debug messages for use in an environment > in which I could not get directly to stderr/stdout. I don't think > anyone uses them anymore. > > -- > Trent Jarvi > tjarvi at qbang.org From ilkka at myller.com Wed Sep 9 23:35:13 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:35:13 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= Message-ID: Hi, Summary: Patch fixes compiling on Linux distributions/kernels that dont ship with linux/utsrelease.h header and therefore have no UTS_RELEASE defined. Usually this applies only to newer distributions and/or kernels - for example Ubuntu 9.04. Fixes: The UTS_RELEASE vs uname checking in initialization functions is now done only in debug build and only when UTS_RELEASE is actually defined. Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910.patch Type: application/octet-stream Size: 9542 bytes Desc: not available URL: From ilkka at myller.com Thu Sep 10 06:43:02 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 15:43:02 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= In-Reply-To: References: Message-ID: Patch has been committed to CVS. > Hi, > > Summary: > > Patch fixes compiling on Linux distributions/kernels that dont ship > with linux/utsrelease.h header and therefore have no UTS_RELEASE > defined. > Usually this applies only to newer distributions and/or kernels - > for example Ubuntu 9.04. > > Fixes: > > The UTS_RELEASE vs uname checking in initialization functions is now > done only in debug build and only when UTS_RELEASE is actually > defined. > > Patch: > > The patch is against CVS head (@2009/09/10). > Attached patch file is in 'cvs diff -up' format. > > > Thanks, > > -- > I > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Thu Sep 10 09:08:01 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 18:08:01 +0300 Subject: [Rxtx] [Patch] Remove unused MathWorks MATLAB DEBUG_MW ifdefs Message-ID: <6DB57DB1-A47E-4435-9CD6-212B671A2849@myller.com> Summary: Patch removes unused MathWorks MATLAB timing debug ifdefs (DEBUG_MW). This is a request from Trent. Fixes: - Removes DEBUG_MW definitions - Removes unused mex....() function definitions - Corrects DEBUG_TIMING to work properly without mexPrintf (with Mac OS X specific format string fixes included) - Removes unused/duplicate timeval struct and DEBUG_TIMING definitions from SerialImp.c and SerialImp.h - Corrects fprintf call in SerialImp.cpp Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910b.patch Type: application/octet-stream Size: 9841 bytes Desc: not available URL: From Kapil_Gupta at hcl.in Thu Sep 10 10:25:29 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 10 Sep 2009 21:55:29 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, I am getting some problem with RXTX on macintosh (reading some data from the device attached to the usb port through usb to serial mechanism). I used the RXTX 2.1.7 then I got PortInUseException but after using 2.2pre it worked fine. But it works only for the first time, it hangs in the second time while opening the port. Please find the attached code. This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Thu Sep 10 13:00:14 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 22:00:14 +0300 Subject: [Rxtx] [Patch] Implement return value checking to file I/O calls Message-ID: Summary: The return value of some functions should always be used. For example, it is dangerous to not check the return value of a write(), read(), open(), fscanf() calls. This patch fixes such occurences in RXTX code. For example: unchecked read() call could result in later - and often seemingly unrelated - segfault due to undefined read buffer contents. After this patch the Linux build process is error/warning free even with gcc -Wall -Werror. Fixes: - Implemented return value checking to file I/O calls in SerialImp.c:fhs_lock(), uucp_lock() and is_device_locked() functions. - Added error recovery for fuserImp.c fscanf() calls. Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910c.patch Type: application/octet-stream Size: 3370 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Thu Sep 10 13:08:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 22:08:05 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> Hi Kapil, I believe this issue has been fixed in CVS version, but still exists in 2.2pre2 available from RXTX wiki. For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html As you've seen from the recent patches announced on this list, we are working very hard to make a new 2.2pre(?) release available. Meanwhile, you can compile your own RXTX binaries from CVS source. On Mac it should be exceptionally easy with new Xcode 3.x project files. Thank you for your patience, -- I > > I am getting some problem with RXTX on macintosh (reading some data > from the device attached to the usb port through usb to serial > mechanism). I used the RXTX 2.1.7 then I got PortInUseException but > after using 2.2pre it worked fine. But it works only for the first > time, it hangs in the second time while opening the port. From ilkka at myller.com Fri Sep 11 04:07:22 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 13:07:22 +0300 Subject: [Rxtx] [Patch] Windows build improvements (MinGW32, MSVC and LCC) Message-ID: <81D06766-8D51-485A-B2A2-624C8EA690BA@myller.com> Summary: Fixes various compiler warnings with Windows builds. Removes unused code blocks from compilation. After this patch the Windows build process is error/warning free with MinGW32, MSVC and LCC compilers - even with -Wall enabled. Does not fix: Latest LCC compiler version still fails even after this patch due to compiler trap error. Trap error does not specify source code location - it fails outputting SerialImp.obj binary. Compiling SerialImp.c without binary output works. Could this be a bug in LCC? Tested with clean RXTX source, latest standard LCC installation and with both Windows Vista SP1 x86 and Windows XP SP3 x86. Patch: The patch is against CVS (@2009/09/11). Attached patch file is in 'cvs diff -up' format. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090911.patch Type: application/octet-stream Size: 6673 bytes Desc: not available URL: From Kapil_Gupta at hcl.in Fri Sep 11 08:21:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Fri, 11 Sep 2009 19:51:24 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Ilkka, I tried getting the source code from the CVS but we could not able to do so, the CVS was not responding. Then we downloaded the 2.2 pre2 code and made the changes that are described in http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html but the problem didn't change. First time the device responds well and the second time it hangs. Did you see the code that we have sent to you, so that you can suggest if we are doing something wrong in our code. Again attaching if you have deleted that. Please suggest (does the CVS code can help rather using the patch provided by you?). Thanks, Kapil -----Original Message----- From: Ilkka Myller [mailto:ilkka at myller.com] Sent: Friday, September 11, 2009 12:38 AM To: Kapil Gupta Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Hi Kapil, I believe this issue has been fixed in CVS version, but still exists in 2.2pre2 available from RXTX wiki. For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html As you've seen from the recent patches announced on this list, we are working very hard to make a new 2.2pre(?) release available. Meanwhile, you can compile your own RXTX binaries from CVS source. On Mac it should be exceptionally easy with new Xcode 3.x project files. Thank you for your patience, -- I > > I am getting some problem with RXTX on macintosh (reading some data > from the device attached to the usb port through usb to serial > mechanism). I used the RXTX 2.1.7 then I got PortInUseException but > after using 2.2pre it worked fine. But it works only for the first > time, it hangs in the second time while opening the port. DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Fri Sep 11 09:33:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 18:33:33 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Hi Kapil, For CVS: Instructions at the old rxtx website are incorrect. Trent updated them, but to a wrong server address "qgang.org" -- the correct server is "qbang.org". Please follow instructions from rxtx wiki: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code About testing your code: When I have time (maybe this weekend), I'll test your code using Mac OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. What USB serial port you are using with your Mac? Something with FTDI chip? or maybe Prolific? What adapter driver version you are using? Just asking, so I can test with the same configuration. Meanwhile I suggest you: - Make sure you have the latest USB Serial adapter drivers, so we can eliminate past issues with those. - Check that you are not having multiple copies of librxtxSerial.jnilib (possibly different versions) in your java library path (=trouble;) - Check for any USB Serial adaptors kernel extension error messages in system log after testing your software (use Console.app to browse logs) -- I Kapil Gupta kirjoitti 11.9.2009 kello 17.21: > Hi Ilkka, > > I tried getting the source code from the CVS but we could not able > to do so, the CVS was not responding. Then we downloaded the 2.2 > pre2 code and made the changes that are described in http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html > but the problem didn't change. First time the device responds well > and the second time it hangs. > > Did you see the code that we have sent to you, so that you can > suggest if we are doing something wrong in our code. Again attaching > if you have deleted that. Please suggest (does the CVS code can help > rather using the patch provided by you?). > > Thanks, > Kapil > > -----Original Message----- > From: Ilkka Myller [mailto:ilkka at myller.com] > Sent: Friday, September 11, 2009 12:38 AM > To: Kapil Gupta > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second > time port open > > Hi Kapil, > > I believe this issue has been fixed in CVS version, but still exists > in 2.2pre2 available from RXTX wiki. > > For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html > > As you've seen from the recent patches announced on this list, we are > working very hard to make a new 2.2pre(?) release available. > > Meanwhile, you can compile your own RXTX binaries from CVS source. On > Mac it should be exceptionally easy with new Xcode 3.x project files. > > > Thank you for your patience, > > > -- > I > > >> >> I am getting some problem with RXTX on macintosh (reading some data >> from the device attached to the usb port through usb to serial >> mechanism). I used the RXTX 2.1.7 then I got PortInUseException but >> after using 2.2pre it worked fine. But it works only for the first >> time, it hangs in the second time while opening the port. > > > DISCLAIMER: > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential > and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of this > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > ----------------------------------------------------------------------------------------------------------------------- > From ilkka at myller.com Fri Sep 11 11:51:13 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 20:51:13 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Message-ID: <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> Ok, I debugged your code on Mac using USB-RS232 adapter + loopback adapter. My findings: there are no issues with RXTX in your code -- there are issues with threading and synchronization. Primary issue: you essentially lock the JVM main thread to 100% CPU usage with infinite loop: while (!processCompleted) { ; } Now.. I'm going to give you a bad advice, mostly because you have bigger threading issues there.. but we must continue somehow: A quick remedy to previous is: while (!processCompleted) { Thread.yield(); } Thread yielding gives other threads atleast a chance to run (and to processCompleted boolean to actually update in main thread context). What happens next is that your main-thread is allowed to continue and proceeds to closeConnection() call it otherwise would never reach. After that, connection closes properly.. main() method continues to "System.out.println(result);" and proceeds to exit JVM.. .. except.. Secondary issue: Exit is one thing JVM cant do since you have left a Timer thread hanging without proper closing in getData() method. Cancel it (uncomment that line) - and your code completes main() to a clean JVM exit. So, my advice to you is to focus on fixing threading, timers and synchronization. Design those well and everything works. Multithreading, done well or not, will not usually confuse RXTX ... but your own code might not be so lucky. -- I > > When I have time (maybe this weekend), I'll test your code using Mac > OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. >> >> Did you see the code that we have sent to you, so that you can >> suggest if we are doing something wrong in our code. Again >> attaching if you have deleted that. Please suggest (does the CVS >> code can help rather using the patch provided by you?). -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 11 15:19:26 2009 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 11 Sep 2009 17:19:26 -0400 Subject: [Rxtx] Can't run my Netbeans/Java s/w on a MAC Message-ID: <4AAABEDE.7020508@howardz.com> An HTML attachment was scrubbed... URL: From ilkka at myller.com Fri Sep 11 15:41:10 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 12 Sep 2009 00:41:10 +0300 Subject: [Rxtx] Can't run my Netbeans/Java s/w on a MAC In-Reply-To: <4AAABEDE.7020508@howardz.com> References: <4AAABEDE.7020508@howardz.com> Message-ID: <35D4BD73-B8CC-4DEE-A846-8858C9C9EBC7@myller.com> Hi, The bug that causes the segfault (invalid memory access) has been fixed (in CVS): http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html Next prerelease is coming (soon I hope), but the the 2.2pre2 fails when reopening the serial port on Mac OS X. -- I > > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] Jar > version = RXTX-2.2pre1 > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] native > lib Version = RXTX-2.2pre2 > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] Invalid > memory access of location 0x12b5e3938 rip=0x12955012f > 9/6/09 3:46:00 PM ReportCrash[6164] Saved crash report for java > [6162] version 13.0.0 (13.0.0) to /Users/myles/Library/Logs/ > DiagnosticReports/java_2009-09-06-154600_myles-PowerBook-PP-108.crash -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Fri Sep 11 20:15:31 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 11 Sep 2009 20:15:31 -0600 (MDT) Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Message-ID: On Fri, 11 Sep 2009, Ilkka Myller wrote: > Hi Kapil, > > For CVS: > > Instructions at the old rxtx website are incorrect. Trent updated them, but > to a wrong server address "qgang.org" -- the correct server is "qbang.org". > Please follow instructions from rxtx wiki: > > http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code The old website has been corrected. -- Trent Jarvi tjarvi at qbang.org From dvd at newfoundmarket.com Sat Sep 12 11:49:48 2009 From: dvd at newfoundmarket.com (DVD) Date: Sat, 12 Sep 2009 13:49:48 -0400 Subject: [Rxtx] RXTX on linux hang Message-ID: <4AABDF3C.2040908@newfoundmarket.com> Hello: I just did a fresh install of RXTZ on both Ubuntu and centos, Java version 6, update 12 I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with the Usage example from your website Two way communcation with the serial port I used the computer's serial port /dev/ttyS0, with UART 16550A the program simply hang. The port was opened and both input/output streamed were opened but the writing/reading are not working. Any help would be appreciated. I tried this program on windows and it worked fine. Thanks From ilkka at myller.com Sat Sep 12 15:31:26 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sun, 13 Sep 2009 00:31:26 +0300 Subject: [Rxtx] RXTX on linux hang In-Reply-To: <4AABDF3C.2040908@newfoundmarket.com> References: <4AABDF3C.2040908@newfoundmarket.com> Message-ID: Hi, It's very hard to say what could be wrong without more details. Can you tell me more about your Linux setup: - Output of: uname -a - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your test code running) - Output of: cat /proc/tty/driver/serial - Are you you testing with root privileges - What kind of device you are communicating with (or just a loopback dongle)? - Does your device expect some specific flow control and/or specific state of DTR/DSR signals? - Have you tried configuring those flow controls and other RS232 signals in your test code? Did they work? - Do other simple terminal programs work (easiest to try: screen /dev/ ttyS0 )? - What is the CPU usage (use 'top' or some other process monitor your like) of your test software when it "hangs"? I can try to duplicate your issue on Ubuntu 9.04 (both x86 and x86_64), Centos 5 (x86) and Debian 5.0 (x86). I'd prefer to test with the same kind of system you have.. Thanks, -- I > > I just did a fresh install of RXTZ on both Ubuntu and centos, Java > version 6, update 12 > I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with > the Usage example from > your website > > Two way communcation with the serial port > > > I used the computer's serial port /dev/ttyS0, with UART 16550A > > the program simply hang. The port was opened and both input/output > streamed were opened > but the writing/reading are not working. > > Any help would be appreciated. I tried this program on windows and > it worked fine. From dvd at newfoundmarket.com Sat Sep 12 21:20:14 2009 From: dvd at newfoundmarket.com (DVD) Date: Sat, 12 Sep 2009 23:20:14 -0400 Subject: [Rxtx] RXTX on linux hang In-Reply-To: References: <4AABDF3C.2040908@newfoundmarket.com> Message-ID: <4AAC64EE.7050904@newfoundmarket.com> Thank you very much for the steps. It is pin out problem. Again, Thanks. Ilkka Myller wrote: > Hi, > > It's very hard to say what could be wrong without more details. > Can you tell me more about your Linux setup: > > - Output of: uname -a > - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your > test code running) > - Output of: cat /proc/tty/driver/serial > - Are you you testing with root privileges > - What kind of device you are communicating with (or just a loopback > dongle)? > - Does your device expect some specific flow control and/or specific > state of DTR/DSR signals? > - Have you tried configuring those flow controls and other RS232 > signals in your test code? Did they work? > - Do other simple terminal programs work (easiest to try: screen > /dev/ttyS0 )? > - What is the CPU usage (use 'top' or some other process monitor your > like) of your test software when it "hangs"? > > > I can try to duplicate your issue on Ubuntu 9.04 (both x86 and > x86_64), Centos 5 (x86) and Debian 5.0 (x86). > I'd prefer to test with the same kind of system you have.. > > > Thanks, > > -- > I > > >> >> I just did a fresh install of RXTZ on both Ubuntu and centos, Java >> version 6, update 12 >> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with >> the Usage example from >> your website >> >> Two way communcation with the serial port >> >> >> >> I used the computer's serial port /dev/ttyS0, with UART 16550A >> >> the program simply hang. The port was opened and both input/output >> streamed were opened >> but the writing/reading are not working. >> >> Any help would be appreciated. I tried this program on windows and >> it worked fine. > From tjarvi at qbang.org Sun Sep 13 12:06:33 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Sep 2009 12:06:33 -0600 (MDT) Subject: [Rxtx] RXTX on linux hang In-Reply-To: <4AAC64EE.7050904@newfoundmarket.com> References: <4AABDF3C.2040908@newfoundmarket.com> <4AAC64EE.7050904@newfoundmarket.com> Message-ID: Hi, Would it be possible to get a short paragraph from you describing the pinout problem and how you discovered it? We can add that to the wiki to help others get past the problem faster next time. On Sat, 12 Sep 2009, DVD wrote: > Thank you very much for the steps. It is pin out problem. > Again, Thanks. > > Ilkka Myller wrote: >> Hi, >> >> It's very hard to say what could be wrong without more details. >> Can you tell me more about your Linux setup: >> >> - Output of: uname -a >> - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your test >> code running) >> - Output of: cat /proc/tty/driver/serial >> - Are you you testing with root privileges >> - What kind of device you are communicating with (or just a loopback >> dongle)? >> - Does your device expect some specific flow control and/or specific state >> of DTR/DSR signals? >> - Have you tried configuring those flow controls and other RS232 signals in >> your test code? Did they work? >> - Do other simple terminal programs work (easiest to try: screen /dev/ttyS0 >> )? >> - What is the CPU usage (use 'top' or some other process monitor your like) >> of your test software when it "hangs"? >> >> >> I can try to duplicate your issue on Ubuntu 9.04 (both x86 and x86_64), >> Centos 5 (x86) and Debian 5.0 (x86). >> I'd prefer to test with the same kind of system you have.. >> >> >> Thanks, >> >> -- >> I >> >> >>> >>> I just did a fresh install of RXTZ on both Ubuntu and centos, Java version >>> 6, update 12 >>> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with the >>> Usage example from >>> your website >>> >>> Two way communcation with the serial port >>> >>> >>> I used the computer's serial port /dev/ttyS0, with UART 16550A >>> >>> the program simply hang. The port was opened and both input/output >>> streamed were opened >>> but the writing/reading are not working. >>> >>> Any help would be appreciated. I tried this program on windows and it >>> worked fine. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dvd at newfoundmarket.com Sun Sep 13 19:18:08 2009 From: dvd at newfoundmarket.com (DVD) Date: Sun, 13 Sep 2009 21:18:08 -0400 Subject: [Rxtx] RXTX on linux hang In-Reply-To: References: <4AABDF3C.2040908@newfoundmarket.com> <4AAC64EE.7050904@newfoundmarket.com> Message-ID: <4AAD99D0.3030206@newfoundmarket.com> Hello, It was a human mistake during wiring and was discovered after staring at it for a while :-). Nothing technical worth mentioning. Thanks Trent Jarvi wrote: > > Hi, > > Would it be possible to get a short paragraph from you describing the > pinout problem and how you discovered it? We can add that to the wiki > to help others get past the problem faster next time. > > On Sat, 12 Sep 2009, DVD wrote: > >> Thank you very much for the steps. It is pin out problem. >> Again, Thanks. >> >> Ilkka Myller wrote: >>> Hi, >>> >>> It's very hard to say what could be wrong without more details. >>> Can you tell me more about your Linux setup: >>> >>> - Output of: uname -a >>> - Output of: stty -a -F /dev/ttyS0 (if possible: with and without >>> your test code running) >>> - Output of: cat /proc/tty/driver/serial >>> - Are you you testing with root privileges >>> - What kind of device you are communicating with (or just a loopback >>> dongle)? >>> - Does your device expect some specific flow control and/or specific >>> state of DTR/DSR signals? >>> - Have you tried configuring those flow controls and other RS232 >>> signals in your test code? Did they work? >>> - Do other simple terminal programs work (easiest to try: screen >>> /dev/ttyS0 )? >>> - What is the CPU usage (use 'top' or some other process monitor >>> your like) of your test software when it "hangs"? >>> >>> >>> I can try to duplicate your issue on Ubuntu 9.04 (both x86 and >>> x86_64), Centos 5 (x86) and Debian 5.0 (x86). >>> I'd prefer to test with the same kind of system you have.. >>> >>> >>> Thanks, >>> >>> -- >>> I >>> >>> >>>> >>>> I just did a fresh install of RXTZ on both Ubuntu and centos, Java >>>> version 6, update 12 >>>> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with >>>> the Usage example from >>>> your website >>>> >>>> Two way communcation with the serial port >>>> >>>> >>>> I used the computer's serial port /dev/ttyS0, with UART 16550A >>>> >>>> the program simply hang. The port was opened and both input/output >>>> streamed were opened >>>> but the writing/reading are not working. >>>> >>>> Any help would be appreciated. I tried this program on windows and >>>> it worked fine. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From Kapil_Gupta at hcl.in Mon Sep 14 08:37:23 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Mon, 14 Sep 2009 20:07:23 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B30A4F25D@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Ilkka, We have done that also, but no success. I am attaching the code, please check the updated code also. We are not using any FTDI/Prolific chip set. We are using TI chip set. We are having only one copy of JNI lib. No Error in console for kernel driver. Warm Regards, Kapil From: Ilkka Myller [mailto:ilkka at myller.com] Sent: Friday, September 11, 2009 11:21 PM To: Kapil Gupta Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Ok, I debugged your code on Mac using USB-RS232 adapter + loopback adapter. My findings: there are no issues with RXTX in your code -- there are issues with threading and synchronization. Primary issue: you essentially lock the JVM main thread to 100% CPU usage with infinite loop: while (!processCompleted) { ; } Now.. I'm going to give you a bad advice, mostly because you have bigger threading issues there.. but we must continue somehow: A quick remedy to previous is: while (!processCompleted) { Thread.yield(); } Thread yielding gives other threads atleast a chance to run (and to processCompleted boolean to actually update in main thread context). What happens next is that your main-thread is allowed to continue and proceeds to closeConnection() call it otherwise would never reach. After that, connection closes properly.. main() method continues to "System.out.println(result);" and proceeds to exit JVM.. .. except.. Secondary issue: Exit is one thing JVM cant do since you have left a Timer thread hanging without proper closing in getData() method. Cancel it (uncomment that line) - and your code completes main() to a clean JVM exit. So, my advice to you is to focus on fixing threading, timers and synchronization. Design those well and everything works. Multithreading, done well or not, will not usually confuse RXTX ... but your own code might not be so lucky. -- I When I have time (maybe this weekend), I'll test your code using Mac OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. Did you see the code that we have sent to you, so that you can suggest if we are doing something wrong in our code. Again attaching if you have deleted that. Please suggest (does the CVS code can help rather using the patch provided by you?). DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10005 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Mon Sep 14 17:03:55 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 15 Sep 2009 02:03:55 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B30A4F25D@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B30A4F25D@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <989B2FAA-5E5A-4F47-AF23-04CE1A6A20F7@myller.com> Kapil, You did not fix the primary issue. Your while() loop still blocks the main thread and the code is not working for the same reasons I stated before. .. but .. I created a demonstration code, which does not try to duplicate the behaviour of your code, but instead demonstrates few concepts: 1. Safe opening of the serial port with full error checking 2. Proper handling of text encoding using Reader/Writer. If your protocol handles plaintext, I recommend you use encoding capable streams. 3. Asynchronous multi-threaded receiving and transmitting (separate thread for each, with their own packet (=string, in this case) queues) 4. Handling serial port data-available events without blocking the event handler (=event only signals async. receiver) 5. Controlling access to serial port in multithreaded app using ReentrantLock (still allows embedded transmit->receive, as demonstrated) 6. Signaling thread from other thread with wait() -> notify() (demonstrated in serial event handling) The code does one simple thing: sends a US-ASCII encoded string to serial port with CR+LF and expects the same line to be received back. I used simple loopback adapter hardware to test this. Normally, doing just this simple task does not require such heavy multi-threading async. receiver/transmitter structures, but I created them to demonstrate various multi-threading concepts, and how they can be used with RXTX. The code is not perfect, it's still a quick hack to demonstrate few things. For example, it lacks proper error handling and propagation in async. receiver/transmitter. However, this code is "profiler clean". It's threads are mostly idle waiting other threads or actual events from RXTX. No thread is blocked in high CPU-% loops etc. when receiving or sending. This also scales nicely to run on multiple CPU's with modern JVM's. When implementing commercial protocol handlers this is how things should always be. Doing "while(someBoolean) {}" is generally not the correct method to sync things. -- I > Hi Ilkka, > > We have done that also, but no success. I am attaching the code, > please check the updated code also. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 11656 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail4ng at gmail.com Tue Sep 15 03:02:48 2009 From: mail4ng at gmail.com (Daniel Weinand) Date: Tue, 15 Sep 2009 11:02:48 +0200 Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby Message-ID: <4AAF5838.7080707@gmail.com> Hello, i'm using RXTX with a USB to Serial Adapter on Linux and Windows machines. Everything works great. but now i have a problem on a Vista machine with standby mode. after the machine wakes up i'll get an infinite error loop: Error 0x5 at ..\src\termios.c(2712): Access Denied Error 0x5 at ..\src\termios.c(517): Access Denied ... and so on. My Application runs as a windows service and so it tries to enumerate and connect to the port directly after it wakes up. but the Port is blocked until i restart the whole machine and everything starts from 0. i'm using rxtx 2.2pre2 is this a known problem and how to solve this? From stefan.frings at vodafone.com Tue Sep 15 11:08:04 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Tue, 15 Sep 2009 17:08:04 +0200 Subject: [Rxtx] Reloading C library after USB error Message-ID: Hello, I wrote a web application that uses rxtxcomm to communicate to USB devices through virtual serial ports (e.g. /dev/ttyUSB0) on Linux. When I unplug a device while the port is open and then plug it back, I cannot access it anymore. I need to kill -9 Tomcat and then restart it. I think that I need to re-load the C library. Another problem occurs when I plug in an USB device after my web application has started. In this case, the new device cannot be accessed through rxtxcomm. Again, I assume that I need to relaod the C library. I am not able to shut-down my web application after these two errors occur. Tomcat reports, that the shut-down failed. How can I reload the C library without hardly killing my running Tomcat? -------------- next part -------------- An HTML attachment was scrubbed... URL: From petter.real at gmail.com Tue Sep 15 16:32:29 2009 From: petter.real at gmail.com (Petter Rafael Villa Real) Date: Tue, 15 Sep 2009 17:32:29 -0300 Subject: [Rxtx] RXTX on Ubuntu 9.04 with lock in /var/lock/LCK..ttyS0. Message-ID: Hi, I always used the RXTX to read/write the serial successfully on Windows. But now I need to use Linux Ubuntu 9.04, I changed to COM1, with on Windows, to /dev/ttyS0, the reading starts on the terminal but the RXTX will warn that you must release the lock of the serial. In the RXTX documentation is indicated add uucd User groups and / or lock to resolve this problem, but in Ubuntu do not have this group. Does anyone have experience with Ubuntu to help me? P.S.: sorry for my bad english. Thank you. -- -- --------------------------------------------------------------------- Petter R. Villa Real Silva -- Desenvolvedor Web Viamais Desenvolvimento Web Powered by Java/Oracle PHP/MySQL Web Alocation e Hosting - PHP/JSP --------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at attglobal.net Tue Sep 15 21:36:38 2009 From: david at attglobal.net (David Schmidt) Date: Tue, 15 Sep 2009 21:36:38 -0400 Subject: [Rxtx] 2.2 Release plans In-Reply-To: References: <4AA7C707.5060802@attglobal.net> Message-ID: <4AB04126.5070002@attglobal.net> Trent Jarvi wrote: > On Wed, 9 Sep 2009, David Schmidt wrote: > >> I'm holding off releasing an update to my project >> (adtpro.sourceforge.net) to support OSX Snow Leopard because I'd like >> to ship an "official" build of rxtx 2.2. (I wouldn't mind shipping >> 2.2Pre2, but it lacks a critical fix for toggling a port off). CVS is >> looking great on OSX - thanks to all who have been hard at work on >> that. I wish there were just one more update - Pre3? :-) >> >> My question... If I wanted to make a release in, say, a week... would >> it pay to wait for rxtx, or should I plan to build and ship a local >> build of 2.2 out of CVS myself? >> > > Hi David, > > I would suggest planning on shipping a local build in a 1 week > timeframe. We could put another prerelease up but there are still fixes > coming in. Thanks for the encouragement, guys. I'm having a little less luck now - building for OSX on an Intel box runs on a PPC box, but not on Intel... weird. I guess I'll wait a bit more. :-) - David From david at attglobal.net Tue Sep 15 21:51:28 2009 From: david at attglobal.net (David Schmidt) Date: Tue, 15 Sep 2009 21:51:28 -0400 Subject: [Rxtx] FTDI chipset speed - much slower? Message-ID: <4AB044A0.10509@attglobal.net> I am finding that my app is behaving really slowly when I'm connecting with a FTDI chipset equipped USB-serial adapter. I'm finding my app to be "fast" when I use native UART ports, Prolific or Keyspan USB adapters. But my FTDI adapters are remarkably, astonishingly slower when sending data (in my case, this means moving data from the DE-9 to the USB end) than any other method. I mean it is maybe 1/5 the "normal" speed I see from every other method. CPU remains calm on the USB (i.e. Mac or PC) end of the adapter. It's just really slow. Data moving in the other direction seems to run at full speed. I'm suspecting I'm doing something wrong along the way that is reacting badly with this chipset. My initial, lazy question, before exposing my code to the harsh light of day: is there anything obvious I might be doing wrong to this chipset to make it run so slowly? Has anyone else run into the same problem? - David From tjarvi at qbang.org Tue Sep 15 22:03:51 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 15 Sep 2009 20:03:51 -0600 (MDT) Subject: [Rxtx] FTDI chipset speed - much slower? In-Reply-To: <4AB044A0.10509@attglobal.net> References: <4AB044A0.10509@attglobal.net> Message-ID: On Tue, 15 Sep 2009, David Schmidt wrote: > I am finding that my app is behaving really slowly when I'm connecting > with a FTDI chipset equipped USB-serial adapter. I'm finding my app to be > "fast" when I use native UART ports, Prolific or Keyspan USB adapters. > But my FTDI adapters are remarkably, astonishingly slower when sending > data (in my case, this means moving data from the DE-9 to the USB end) > than any other method. I mean it is maybe 1/5 the "normal" speed I see > from every other method. CPU remains calm on the USB (i.e. Mac or PC) end > of the adapter. It's just really slow. Data moving in the other > direction seems to run at full speed. > > I'm suspecting I'm doing something wrong along the way that is reacting > badly with this chipset. My initial, lazy question, before exposing my > code to the harsh light of day: is there anything obvious I might be doing > wrong to this chipset to make it run so slowly? Has anyone else run into > the same problem? > Given that rxtx does not treat usb special, it may be something to do with the nature of USB serial dongles. One suspicion I've had is that the event loop is competing for bandwidth by trying to check the UART status which is on the other side of the USB line. 1/5th is fairly significant. This is just writing/reading? How large are the transfers? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 15 22:07:12 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 15 Sep 2009 20:07:12 -0600 (MDT) Subject: [Rxtx] Reloading C library after USB error In-Reply-To: References: Message-ID: On Tue, 15 Sep 2009, Frings, Stefan, VF-DE wrote: > Hello, > ? > I wrote a web application that uses rxtxcomm to communicate to USB > devices through virtual serial ports (e.g. /dev/ttyUSB0) on Linux. > ? > When I unplug a device while the port is open and then plug it back, I > cannot access it anymore. I need to kill -9 Tomcat and then restart it. I > think that?I need to re-load the C library. > ? > Another problem occurs when I plug in an USB device after my web > application has started. In this case, the new device cannot be accessed > through rxtxcomm. Again, I assume that I need to relaod the C library. > ? > I am not able to shut-down my web application after these two errors > occur.? Tomcat reports, that the shut-down failed. > ? > How can I reload the C library without hardly killing my running Tomcat? > > I don't think the native library needs to shut down but the code does not expect the file descriptor to go invalid. Duct taping the USB dongle isnt always an option but thats how rxtx is currently coded. read/write and the event loop could all fail at any time and need to shut down the port. This code is not in place. We don't get USB events through the API so it has to be done by checking errors. The library also needs the ability to rescan the available ports. When it was written, you had to shut down the computer to remove a serial port so rescanning wasnt a concern. If those two fixes are made, you will be able to exit tomcat gracefully. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 15 22:08:54 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 15 Sep 2009 20:08:54 -0600 (MDT) Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby In-Reply-To: <4AAF5838.7080707@gmail.com> References: <4AAF5838.7080707@gmail.com> Message-ID: On Tue, 15 Sep 2009, Daniel Weinand wrote: > Hello, > > i'm using RXTX with a USB to Serial Adapter on Linux and Windows machines. > Everything works great. > but now i have a problem on a Vista machine with standby mode. after the > machine wakes up i'll get an infinite error loop: > > > Error 0x5 at ..\src\termios.c(2712): Access Denied > Error 0x5 at ..\src\termios.c(517): Access Denied > ... > > and so on. > > My Application runs as a windows service and so it tries to enumerate and > connect to the port directly > after it wakes up. but the Port is blocked until i restart the whole > machine and everything starts from 0. > > i'm using rxtx 2.2pre2 > > is this a known problem and how to solve this? It is a known problem. The kernel driver isnt restoring the fd. See the previous post for what is required prior to being able to handle it in your code. -- Trent Jarvi tjarvi at qbang.org From nsp25 at cornell.edu Tue Sep 15 22:50:11 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 15 Sep 2009 22:50:11 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> Message-ID: Thank you very much Ikka and Mike. Sorry I didn't get back sooner, but your emails got buried in my inbox, and I didn't see them until yesterday, or get to try it out until today. The following body of the connect method worked (same serial cable): SerialPort port = (SerialPort) CommPortIdentifier.getPortIdentifier("COM1").open("", 1000); port.setSerialPortParams(baud, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); // Never tried this before, it was just one or the other port.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT); port.setRTS(true); // Seems to work when flow control is set right port.setDTR(false); // Just in case port.disableReceiveTimeout(); However, I noticed what could be a bug in RXTX for Windows XP. While running PortMon, I discovered what could be problems in the (attached) log file, namely INVALID_PARAMETER return codes for IOCTL_SERIAL_CLR_RTS happens, I believe) and twice for IOCTL_SERIAL_SET_RTS. The log is nearly identical each time I connect, with the same failures. What's the easiest way I can run RXTX in debug mode? I have visual studio 2008, if that helps. If anyone wants to help me track this (new?) bug down, I can provide whatever computer information you ask for. -Nate On Wed, Sep 9, 2009 at 8:57 AM, Michael Tandy wrote: > OK, I just ran a test with my copy of RxTx and the following program: > > import gnu.io.*; > public class SerialTest { > public static void main(String[] args) { > > try { > CommPortIdentifier portid = > CommPortIdentifier.getPortIdentifier("COM9"); > SerialPort serialPort = (SerialPort)portid.open("Serial > port DTR/RTS test", 1000); > serialPort.setSerialPortParams(4800, > SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > serialPort.disableReceiveTimeout(); > for (int i=0 ; i<60 ; i++) { > serialPort.setDTR(true); > serialPort.setRTS(true); > Thread.sleep(1000); > serialPort.setDTR(false); > serialPort.setRTS(false); > Thread.sleep(1000); > } > } catch (Exception e) { > e.printStackTrace(); > System.exit(1); > } > System.exit(0); > } > } > > I'm using a USB-serial converter (Prolific PL-2303) and I used a > multimeter to check that my DTR and RTS pins were both toggling, and > they were - between +7 and -6.4 volts. > > In other words, on the computer I'm using at the moment, with the > version of RxTx I'm using at the moment, setDTR and setRTS both seem > to work fine. I don't know if it's worth it for you to perform the > same test. > > I gather there are several different configurations for hardware flow > control, (DTR/DSR handshaking as well as RTS/CTS handshaking, > handshaking for half-duplex operation, and similar) so the cable that > worked for me might still be worth a try. > > > 2009/9/9 Michael Tandy : > > I had a similar problem a while ago - hardware that would work with > > Hyperterminal but not with Rxtx. > > > > I don't know if this is a bug in RxTx or not - I tried to find where > > in the RxTx source code those functions are actually implemented - I > > got as far as the ioctl function in termios.c, where the TIOCMSET case > > sets the MSR byte in the termios struct, but I can't figure out where > > that gets written to the dcb struct's fDtrControl dword. It could be a > > bug, or it could just be me missing something. > > > > In any case, at the time I had this problem I wasn't equipped to debug > > RxTx so instead I created a special cable to satisfy the hardware's > > flow control while leaving the data connection straight through. > > Here's how I connected it: > > > > At the female end of the cable (i.e. the hardware I was connecting to) > > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > > I connected the ground and data pins straight through - that is, pin 5 > > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > > 3 female end to pin 3 male end. > > > > Anyway, using that cable bypassed the hardware's flow control, and got > > RxTx working just as well as HyperTerminal - although I slowed down my > > communication to make sure I didn't encounter a situation where the > > flow control would have come into effect, as I had bypassed it! > > > > Hope that helps. > > > > > > 2009/9/9 Nathaniel S. Parsons : > >> I added a call to setRTS() but nothing changed in Serial Port Monitor, > no > >> matter what the argument was. Is this a bug, or did I call the wrong > >> function? > >> > >> I tried to find the c code behind this function, and I think I found it > in > >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look > wrong > >> to me. Am I looking at the right function or is the problem somewhere > else? > >> > >> -Nate > >> > >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > > >> wrote: > >>> > >>> Thanks for the response. I'll try to get to the electronics store > tomorrow > >>> to get more serial cables, even if it isn't the problem. > >>> > >>> I am using a different serial cable than I was in the spring. It's > >>> actually a Male/Female cable with a female-female adapter since the old > >>> cables aren't around anymore. The hardware's manual says nothing except > to > >>> use a "Straight cable" but I figured that if it worked in > HyperTerminal, it > >>> should work in RXTX, right? > >>> > >>> Anyways, I've also noticed some things that are different between > >>> HyperTerminal, RXTX, and a separate program I found that communicates > with > >>> the device (but doesn't do what I want, which is why I'm rolling my own > >>> program) > >>> > >>> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS > and > >>> DTR indicators are green > >>> Other program - not sure what settings it thinks it's using, but only > >>> SPM's RTS indicator is green > >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR > >>> indicators are on. > >>> > >>> From Serial Port Monitor's help files (paraphrased): the indicators > >>> display the state of the serial control lines > >>> > >>> RTS - Request To Send > >>> CTS - Clear To Send > >>> DTR - Data Terminal Ready > >>> > >>> Could this be related to the problem? > >>> > >>> -Nate > >>> > >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy > > >>> wrote: > >>>> > >>>> OK, so: > >>>> > >>>> 1. It worked in spring but has stopped doing so and > >>>> 2. The data all arrives at once when you start hyperterminal. > >>>> > >>>> Is it possible you're using a different serial cable to connect to the > >>>> device, compared to the one you were using in spring? > >>>> > >>>> If so, the issue might be hardware flow control - that is, your device > >>>> might be buffering data because it can't transmit it until your > >>>> computer sets 'DTR' or 'RTS' or something like that. > >>>> > >>>> One way of bypassing hardware flow control is by using cables which > >>>> cross over certain wires so that the right signals are always being > >>>> sent; it's possible your old cable had these connections but your > >>>> current cable doesn't have them. If you can find the old cable, you > >>>> could put it back in and see if that fixes things? > >>>> > >>>> > >>>> 2009/9/8 Nathaniel S. Parsons : > >>>> > (Sorry if this is a double post, but I sent my original message > without > >>>> > subscribing, and since this is an urgent problem, I thought I'd > resend > >>>> > after > >>>> > subscribing to bypass the moderator limbo zone) > >>>> > > >>>> > Hi all, > >>>> > > >>>> > I've asked my question on StackOverflow already, so rather than > >>>> > copy-paste > >>>> > the question here, I'd like to redirect you there. > >>>> > > >>>> > Short version, I am no longer able to receive anything over RS-232 > with > >>>> > RXTX, but other programs work fine. I'm definitely sending things, > >>>> > because > >>>> > when I connect with a different program, all the responses to the > >>>> > commands I > >>>> > sent via RXTX arrive all at once. > >>>> > > >>>> > Everything was fine in the spring, so what could have happened? > Windows > >>>> > update? > >>>> > > >>>> > -Nate > >>>> > > >>>> > _______________________________________________ > >>>> > Rxtx mailing list > >>>> > Rxtx at qbang.org > >>>> > http://mailman.qbang.org/mailman/listinfo/rxtx > >>>> > > >>>> > > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at qbang.org > >>>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: connection_log.csv Type: application/octet-stream Size: 9725 bytes Desc: not available URL: From stefan.frings at vodafone.com Wed Sep 16 02:06:52 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Wed, 16 Sep 2009 08:06:52 +0200 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time Message-ID: Hello Daniel Weinand, your proble is surely related to my issue. Im not familiar with Mac OS, but I know that Linux and also Windows normally disconnect all USB devices during standby mode and reconnect them after power-on. RxTx seems to have a problem when a device disappears or appears while the C library is loaded. I think the C library should be changed to re-check the list of available ports whenever the Java application attempts to enumerate or open a port. And when a port disappears while it is open, the library should close it and throw an AlreadyClosedException. I think the Java application should be able to recover itself from temporarily lost devices, and it should also be able to open devices that have been plugged in AFTER the library was loaded. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.frings at vodafone.com Wed Sep 16 02:09:34 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Wed, 16 Sep 2009 08:09:34 +0200 Subject: [Rxtx] Reloading C library after USB error In-Reply-To: References: Message-ID: Hello Trent, Yes, I think the same. The library was obviously not written for USB devices. Is anybody aware of an alternative that works fine with USB / Hotpluggable devices? From stefan.frings at vodafone.com Wed Sep 16 02:12:58 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Wed, 16 Sep 2009 08:12:58 +0200 Subject: [Rxtx] RXTX on Ubuntu 9.04 with lock in /var/lock/LCK..ttyS0 Message-ID: Hello Petter, the serial ports are normally only writeable by root and by users that are in the dialout group. For your case, a solution might be, to add yourself to the dialout group in /etc/group. On my machines, RxTx wporks fine. I am using Ubuntu 8.10 and 9.04 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.frings at vodafone.com Wed Sep 16 02:17:27 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Wed, 16 Sep 2009 08:17:27 +0200 Subject: [Rxtx] FTDI chipset speed - much slower? Message-ID: Hello David, Im not 100% sure, but I highly assume that the delays are produces by the USB communication. USB transfers data in packets and there are large buffers of several hundreds characters, similar to ethernet. There is no real time communication. So when your software thinks that it has sent a character, this was not the case. It was only put into a buffer and will appears at the end of your USB2Serial cable after some time - I assume somewhat around 0,3ms. I noticed the same behavious with different USB2Serial adapters on Linux with plain C programs (not anything around Java and RxTx). -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 16 03:06:41 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 16 Sep 2009 10:06:41 +0300 Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby In-Reply-To: References: <4AAF5838.7080707@gmail.com> Message-ID: <0EB22ACB-0676-44DE-BBD3-A9D38CFD2E88@myller.com> Windows is not my primary platform, but I agree with Trent. I tested this too and noticed that ClearCommError() does not fail because RXTX loses fd (why would it), but because fd seems to no longer exist, or is reused, on kernel side. Resulting in access denied (5) error. Definitely something RXTX has no control of. Also the USB device re-registers itself, causing all it's previous file handles invalidated. After few seconds after waking from sleep, new ones can be created with CreateFile calls - as expected. FTDI chips can be reprogrammed not to do this reconnection cycle on USB sleep (with mprog 3.5 software). I dont know how well Windows follows that setting. Also Windows allows disabling USB power saving on specific USB devices. After those settings, it entirely up to the USB driver to do the right thing. .. which I'm not entirely sure it will - even if it's technically possible to retain fd's over sleep the driver might still be hardwired to reconnect the device on power save events. -- Basicly all these issues are about the fact that someone/something rips off the UART hardware RXTX is controlling. The serial comms features on most operating systems are not equipped to handle this since UART is expected to be integral part of the system. Well, USB has certainly changed that. Now not only the serial device can be unplugged (which is handled properly by protocols etc.) but the actual interface hardware too. Like ripping off the engine from your car while driving. For those reasons this issue is very hard for RXTX or any other serial comms library to handle. We could detect errors from kernel that indicate the UART has vanished and proceed to do automatic reopening of the serial port after some delay at the native lib. But: this has multiple issues, which probably will break user protocols and software. One of those is the fact that reopening the port could toggle its CTS/RTS/DTR/DSR signals causing unexpected trouble on user side. Other one is that we might end up in infinite loop of comm error <-> automatic reopening without notifying rxtx java side. Not elegant. Not proper. -- I'm proposing a following solution: We could implement a method to detect lost UART in event loop at native lib side and introduce a new Java side SerialPortEvent type UART_DISCONNECT. The native lib would send that event in case of error and proceed to automatically close the serial port and clear the invalid handles etc. (reset to fault free state). That would allow user code to gracefully handle these situations, by doing whatever is necessary to restore communications with their protocols etc. Usually that includes opening the serial port and doing some initializations. Those who choose to ignore that event, or not implement any handling for it, can continue to use RXTX as any other serial comms lib. But their software would still tumble and fall on UART disconnects - mostly caused by USB->UART bridges. Atleast, we'd have a method for implementing proper recovery if RXTX user chooses to do so. Beats duct tape+USB dongle combo anytime;) Feedback welcome :) -- I > > > On Tue, 15 Sep 2009, Daniel Weinand wrote: >> >> Error 0x5 at ..\src\termios.c(2712): Access Denied >> Error 0x5 at ..\src\termios.c(517): Access Denied >> ... > > It is a known problem. The kernel driver isnt restoring the fd. > See the previous post for what is required prior to being able to > handle it in your code. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 16 03:18:14 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 16 Sep 2009 10:18:14 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time In-Reply-To: References: Message-ID: I'm referring to my previous post and to my proposal for handling these situations (detection + java side event): In addition to UART_DISCONNECT event I proposed, your suggestion about AlreadyClosedException is great. We'd still have to handle existing "opened port objects" in Java side even after sending the UART_DISCONNECT event. Making them throw AlreadyClosedException would do that elegantly. -- I Frings, Stefan, VF-DE kirjoitti 16.9.2009 kello 9.06: > > And when a port disappears while it is open, the library should > close it and throw an AlreadyClosedException. > > I think the Java application should be able to recover itself from > temporarily lost devices, and it should also be able to open devices > that have been plugged in AFTER the library was loaded. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at attglobal.net Wed Sep 16 05:47:59 2009 From: david at attglobal.net (David Schmidt) Date: Wed, 16 Sep 2009 05:47:59 -0400 Subject: [Rxtx] FTDI chipset speed - much slower? In-Reply-To: References: <4AB044A0.10509@attglobal.net> Message-ID: <4AB0B44F.9060201@attglobal.net> Trent Jarvi wrote: > On Tue, 15 Sep 2009, David Schmidt wrote: >> I'm suspecting I'm doing something wrong along the way that is >> reacting badly with this chipset. My initial, lazy question, before >> exposing my code to the harsh light of day: is there anything obvious >> I might be doing wrong to this chipset to make it run so slowly? Has >> anyone else run into the same problem? > > Given that rxtx does not treat usb special, it may be something to do > with the nature of USB serial dongles. One suspicion I've had is that > the event loop is competing for bandwidth by trying to check the UART > status which is on the other side of the USB line. > > 1/5th is fairly significant. This is just writing/reading? How large > are the transfers? The protocol is a little dance that happens with tiny packets, rapidly sending/receiving (http://adtpro.sourceforge.net/protocol.html#Get). Host sends: 2 bytes: current block number (LSB, MSB) 1 byte: half-block number (2 = bytes 0-255, 1 = bytes 256-511) up to 256 bytes: Half-block, RLE encoded two bytes: CRC (lo) CRC (hi) Apple sends: One byte: acknowledgement Two bytes: current block number (LSB, MSB) One byte: half-block number (2 = bytes 0-255, 1 = bytes 256-511) (repeat) As others have mentioned, it may be the chipset waiting until that 16-byte on-chip buffer fills up, as the acknowledgment packet is really small. And, the payload packet size can be really small if all bytes are the same - RLE encoding would pack an "empty" block into just a few bytes too. - David From ozgurovic at hotmail.com Wed Sep 16 07:09:37 2009 From: ozgurovic at hotmail.com (Ozgur Erkent) Date: Wed, 16 Sep 2009 14:09:37 +0300 Subject: [Rxtx] FTDI chipset speed - much slower? In-Reply-To: <4AB0B44F.9060201@attglobal.net> References: <4AB044A0.10509@attglobal.net> <4AB0B44F.9060201@attglobal.net> Message-ID: Has anybody tried to experiment the latency time of FTDI USB2Serial? (its latency wrt serial port) after preferably sending command from the computer, probably by keeping track of time after command is sent, its echo back time. In different languages would be good to compare them. ?zg?r Erkent > Date: Wed, 16 Sep 2009 05:47:59 -0400 > From: david at attglobal.net > To: rxtx at qbang.org > Subject: Re: [Rxtx] FTDI chipset speed - much slower? > > Trent Jarvi wrote: > > On Tue, 15 Sep 2009, David Schmidt wrote: > >> I'm suspecting I'm doing something wrong along the way that is > >> reacting badly with this chipset. My initial, lazy question, before > >> exposing my code to the harsh light of day: is there anything obvious > >> I might be doing wrong to this chipset to make it run so slowly? Has > >> anyone else run into the same problem? > > > > Given that rxtx does not treat usb special, it may be something to do > > with the nature of USB serial dongles. One suspicion I've had is that > > the event loop is competing for bandwidth by trying to check the UART > > status which is on the other side of the USB line. > > > > 1/5th is fairly significant. This is just writing/reading? How large > > are the transfers? > > The protocol is a little dance that happens with tiny packets, rapidly > sending/receiving (http://adtpro.sourceforge.net/protocol.html#Get). > > Host sends: > 2 bytes: current block number (LSB, MSB) > 1 byte: half-block number (2 = bytes 0-255, 1 = bytes 256-511) > up to 256 bytes: Half-block, RLE encoded > two bytes: > CRC (lo) > CRC (hi) > > Apple sends: > One byte: acknowledgement > Two bytes: current block number (LSB, MSB) > One byte: half-block number (2 = bytes 0-255, 1 = bytes 256-511) > > (repeat) > > As others have mentioned, it may be the chipset waiting until that > 16-byte on-chip buffer fills up, as the acknowledgment packet is really > small. And, the payload packet size can be really small if all bytes > are the same - RLE encoding would pack an "empty" block into just a few > bytes too. > > - David > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ More than messages?check out the rest of the Windows Live?. http://www.microsoft.com/windows/windowslive/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Wed Sep 16 07:15:23 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Wed, 16 Sep 2009 07:15:23 -0400 (EDT) Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby In-Reply-To: <0EB22ACB-0676-44DE-BBD3-A9D38CFD2E88@myller.com> Message-ID: <11479259.481253099719746.JavaMail.gjohnson@pippin.local> This is a big problem for us, and one we have resorted to the duct tape solution for as we can't find anything better :( The notion of an additional event coming up from the native code sounds very promising! Cheers, greg -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com ----- Original Message ----- From: "Ilkka Myller" To: "Trent Jarvi" , "Daniel Weinand" , "Stefan Frings, VF-DE" Cc: "rxtx at qbang.org" Sent: Wednesday, September 16, 2009 3:06:41 AM GMT -05:00 US/Canada Eastern Subject: Re: [Rxtx] Error 0x5 in termios.c after wake-up from standby Windows is not my primary platform, but I agree with Trent. I tested this too and noticed that ClearCommError() does not fail because RXTX loses fd (why would it), but because fd seems to no longer exist, or is reused, on kernel side. Resulting in access denied(5) error. Definitely something RXTX has no control of. Also the USB device re-registers itself, causing all it's previous file handles invalidated. After few seconds after waking from sleep, new ones can be created with CreateFile calls - as expected. FTDI chips can be reprogrammed not to do this reconnection cycle on USB sleep (with mprog 3.5 software). I dont know how well Windows follows that setting. Also Windows allows disabling USB power saving on specific USB devices. After those settings, it entirely up to the USB driver to do the right thing. .. which I'm not entirely sure it will - even if it's technically possible to retain fd's over sleep the driver might still be hardwired to reconnect the device on power save events. -- Basicly all these issues are about the fact that someone/something rips off the UART hardware RXTX is controlling. The serial comms features on most operating systems are not equipped to handle this since UART is expected to be integral part of the system. Well, USB has certainly changed that. Now not only the serial device can be unplugged (which is handled properly by protocols etc.) but the actual interface hardware too. Like ripping off the engine from your car while driving. For those reasons this issue is very hard for RXTX or any other serial comms library to handle. We could detect errors from kernel that indicate the UART has vanished and proceed to do automatic reopening of the serial port after some delay at the native lib. But: this has multiple issues, which probably will break user protocols and software. One of those is the fact that reopening the port could toggle its CTS/RTS/DTR/DSR signals causing unexpected trouble on user side. Other one is that we might end up in infinite loop of comm error <-> automatic reopening without notifying rxtx java side. Not elegant. Not proper. -- I'm proposing a following solution: We could implement a method to detect lost UART in event loop at native lib side and introduce a new Java side SerialPortEvent type UART_DISCONNECT. The native lib would send that event in case of error and proceed to automatically close the serial port and clear the invalid handles etc. (reset to fault free state). That would allow user code to gracefully handle these situations, by doing whatever is necessary to restore communications with their protocols etc. Usually that includes opening the serial port and doing some initializations. Those who choose to ignore that event, or not implement any handling for it, can continue to use RXTX as any other serial comms lib. But their software would still tumble and fall on UART disconnects - mostly caused by USB->UART bridges. Atleast, we'd have a method for implementing proper recovery if RXTX user chooses to do so. Beats duct tape+USB dongle combo anytime;) Feedback welcome :) -- I On Tue, 15 Sep 2009, Daniel Weinand wrote: Error 0x5 at ..\src\termios.c(2712): Access Denied Error 0x5 at ..\src\termios.c(517): Access Denied ... It is a known problem. The kernel driver isnt restoring the fd. See the previous post for what is required prior to being able to handle it in your code. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Wed Sep 16 07:42:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 16 Sep 2009 05:42:08 -0600 (MDT) Subject: [Rxtx] FTDI chipset speed - much slower? In-Reply-To: References: Message-ID: On Wed, 16 Sep 2009, Frings, Stefan, VF-DE wrote: > Hello David, > ? > Im not 100% sure, but I highly assume that the delays are produces by the > USB communication. USB transfers data in packets and there are large > buffers of several hundreds characters, similar to ethernet. There is no > real time communication. > ? > So when your software thinks that it has sent a character, this was not > the case. It was only put into a buffer and will appears at the end of > your USB2Serial cable after some time - I assume somewhat around 0,3ms. > ? > I noticed the same behavious with different USB2Serial adapters on Linux > with plain C programs (not anything around Java and RxTx). > ? I have seen some simple native C applications that do not inspect the LSR manage to send bytes closer to how an onboard UART does. In that case it was just two bytes being observed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Sep 16 07:55:14 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 16 Sep 2009 05:55:14 -0600 (MDT) Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby In-Reply-To: <0EB22ACB-0676-44DE-BBD3-A9D38CFD2E88@myller.com> References: <4AAF5838.7080707@gmail.com> <0EB22ACB-0676-44DE-BBD3-A9D38CFD2E88@myller.com> Message-ID: I think that will be fine. I'm not sure about all the corner cases with bluetooth dongles. On Wed, 16 Sep 2009, Ilkka Myller wrote: > Windows is not my primary platform, but I agree with Trent. > > I tested this too and noticed that ClearCommError() does not fail because > RXTX loses fd (why would it), but because fd seems to no longer exist, or > is reused, on kernel side. Resulting in access denied(5) error. > Definitely something RXTX has no control of. > Also the USB device re-registers itself, causing all it's previous file > handles invalidated. After few seconds after waking from sleep, new ones > can be created with CreateFile calls - as expected. > > FTDI chips can be reprogrammed not to do this reconnection cycle on USB > sleep (with mprog 3.5 software). I dont know how well Windows follows > that setting. Also Windows allows disabling USB power saving on specific > USB devices. > > After those settings, it entirely up to the USB driver to do the right > thing. .. which I'm not entirely sure it will - even if it's technically > possible to retain fd's over sleep the driver might still be hardwired to > reconnect the device on power save events. > > -- > > Basicly all these issues are about the fact that someone/something rips > off the UART hardware RXTX is controlling. The serial comms features on > most operating systems are not equipped to handle this since UART is > expected to be integral part of the system. Well, USB has certainly > changed that.? > Now not only the serial device can be unplugged (which is handled > properly by protocols etc.) but the actual interface hardware too. Like > ripping off the engine from your car while driving. > > For those reasons this issue is very hard for RXTX or any other serial > comms library to handle. We could detect errors from kernel that indicate > the UART has vanished and proceed to do automatic reopening of the serial > port after some delay at the native lib. But: this has multiple issues, > which probably will break user protocols and software. One of those is > the fact that reopening the port could toggle its CTS/RTS/DTR/DSR signals > causing unexpected trouble on user side. Other one is that we might end > up in infinite loop of comm error <-> automatic reopening without > notifying rxtx java side. Not elegant. Not proper. > > -- > > I'm proposing a following solution: > > We could implement a method to detect lost UART in event loop at native > lib side and introduce a new Java side SerialPortEvent type > UART_DISCONNECT.?The native lib would send that event in case of error > and proceed to automatically close the serial port and clear the invalid > handles etc. (reset to fault free state). > > That would allow user code to gracefully handle these situations, by > doing whatever is necessary to restore communications with their > protocols etc. Usually that includes opening the serial port and doing > some initializations. > > Those who choose to ignore that event, or not implement any handling for > it, can continue to use RXTX as any other serial comms lib. But their > software would still tumble and fall on UART disconnects - mostly caused > by USB->UART bridges. > > Atleast, we'd have a method for implementing proper recovery if RXTX user > chooses to do so. Beats duct tape+USB dongle combo anytime;) > > Feedback welcome :)? > > -- > I > > > > On Tue, 15 Sep 2009, Daniel Weinand wrote: > > Error 0x5 at ..\src\termios.c(2712): Access > Denied > > Error 0x5 at ..\src\termios.c(517): Access Denied > > ... > > > It is a known problem. ?The kernel driver isnt restoring the > fd. ?See the previous post for what is required prior to > being able to handle it in your code. > > > From tjarvi at qbang.org Tue Sep 1 02:38:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 1 Sep 2009 02:38:40 -0600 (MDT) Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks Ilkka The problem should be resolved (confirmed from two locations). I'll be trying to hunt down a Snow Leopard box tomorrow evening as well. On Tue, 1 Sep 2009, Ilkka Myller wrote: > Hi, > > CVS server is reachable, but when trying anonymous login it replies: > > " > Fatal error, aborting. > anonymous: no such system user > " > > It seems that the anonymous cvs account is not yet properly configured on the > new system. > > -- > I > >> On Mon, 31 Aug 2009, Trent Jarvi wrote: >> >> The server has been beemed to another location for those experiencing >> routing problems. >> >> in bash: >> >> export CVSROOT=:pserver:anonymous at qbang.org:2401/var/cvs/cvsroot >> cvs login (no passwd) >> cvs co -r commapi-0-0-1 rxtx-devel >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Tue Sep 1 03:05:59 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 12:05:59 +0300 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks, The new CVS server works well :) I can also confirm that latest CVS version builds properly with unmodified Snow Leopard (Mac OS X 10.6) system: Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 gcc version 4.2.1 (Apple Inc. build 5646) Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) --> Resulting JNI library (Universal Binary): i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = 9d15fc488b301da8bf65b2c9456a7bbb --> Resulting JAR: RXTXComm.jar / 60942 bytes MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 Atleast it builds.. and probably works too. I have not tested that yet. -- I Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > The problem should be resolved (confirmed from two locations). I'll > be trying to hunt down a Snow Leopard box tomorrow evening as well. From jimmy.lee at emotum.com Tue Sep 1 05:07:19 2009 From: jimmy.lee at emotum.com (Jimmy Lee [emotum]) Date: Tue, 1 Sep 2009 21:07:19 +1000 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: <112685a90909010407i6054acb5tc2b12196797bfaf1@mail.gmail.com> Could we access to the binaries? Please :) 2009/9/1 Ilkka Myller > Thanks, > > The new CVS server works well :) > > I can also confirm that latest CVS version builds properly with unmodified > Snow Leopard (Mac OS X 10.6) system: > > Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_I386 i386 > gcc version 4.2.1 (Apple Inc. build 5646) > Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) > > > --> Resulting JNI library (Universal Binary): > > i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes > > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 > librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc > > MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = > 9d15fc488b301da8bf65b2c9456a7bbb > > > --> Resulting JAR: > > RXTXComm.jar / 60942 bytes > > MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 > > > > Atleast it builds.. and probably works too. I have not tested that yet. > > -- > I > > Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > > The problem should be resolved (confirmed from two locations). I'll be >> trying to hunt down a Snow Leopard box tomorrow evening as well. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Tue Sep 1 06:21:28 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Tue, 1 Sep 2009 08:21:28 -0400 (EDT) Subject: [Rxtx] Snow Leopard binaries Message-ID: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> +1 for binaries - pretty please with sugar on top... -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com From fredm at alum.mit.edu Tue Sep 1 06:24:17 2009 From: fredm at alum.mit.edu (Fred G. Martin) Date: Tue, 1 Sep 2009 08:24:17 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> Message-ID: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> You can find one here: http://iharder.sourceforge.net/current/java/ Also, you need to add yourself (any rxtx user) to the uucp group. Niutils don't exist, but dscl is a replacement. There is info for using it here: http://aplawrence.com/MacOSX/directory_services.html Fred On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Tue Sep 1 07:03:37 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Tue, 1 Sep 2009 18:33:37 +0530 Subject: [Rxtx] Help for RXTX on mac Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time I am able to read the device but on second time, it hangs on COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then it was showing the PortInUseException, I replaced the RXTX library to 2.2Pre1 so it is showing this problem. Is this is a problem with RXTX on Mac? Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: From ilkka at myller.com Tue Sep 1 07:57:06 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 16:57:06 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:02:31 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:02:31 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:43:49 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:43:49 +0300 Subject: [Rxtx] Help for RXTX on mac In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE@myller.com> Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Arseneau at Sun.COM Tue Sep 1 08:51:32 2009 From: Eric.Arseneau at Sun.COM (Eric Arseneau) Date: Tue, 01 Sep 2009 07:51:32 -0700 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24@sun.com> Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 09:24:30 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 18:24:30 +0300 Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D@myller.com> Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Thu Sep 3 02:50:16 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Thu, 3 Sep 2009 10:50:16 +0200 Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s From Kapil_Gupta at hcl.in Thu Sep 3 06:52:21 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:22:21 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From Kapil_Gupta at hcl.in Thu Sep 3 07:15:19 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:45:19 +0530 Subject: [Rxtx] Rxtx Digest, Vol 25, Issue 3 In-Reply-To: References: Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C50BB@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi myller, I have attached the code with the mail. Please help me if I am doing something wrong in it. Thanks & Regards, Kapil Gupta -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of rxtx-request at qbang.org Sent: Thursday, September 03, 2009 4:15 PM To: rxtx at qbang.org Subject: Rxtx Digest, Vol 25, Issue 3 Send Rxtx mailing list submissions to rxtx at qbang.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qbang.org/mailman/listinfo/rxtx or, via email, send a message with subject or body 'help' to rxtx-request at qbang.org You can reach the person managing the list at rxtx-owner at qbang.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Rxtx digest..." Today's Topics: 1. Re: Snow Leopard binaries (Ilkka Myller) 2. Re: Snow Leopard binaries (Ilkka Myller) 3. Re: Help for RXTX on mac (Ilkka Myller) 4. Re: Snow Leopard binaries (Eric Arseneau) 5. Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters (Ilkka Myller) 6. RXTX multiple crashes (Kjetil ?ster?s) 7. RXTX 2.2Pre + MacMini+ Deadlock while second time port open (Kapil Gupta) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Sep 2009 16:57:06 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 1 Sep 2009 17:02:31 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <55EC133D-DC83-45A3-849C-02714904D580 at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 1 Sep 2009 17:43:49 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Help for RXTX on mac Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Tue, 01 Sep 2009 07:51:32 -0700 From: Eric Arseneau Cc: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24 at sun.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 1 Sep 2009 18:24:30 +0300 From: Ilkka Myller To: rxtx Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Thu, 3 Sep 2009 10:50:16 +0200 From: Kjetil ?ster?s To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s ------------------------------ Message: 7 Date: Thu, 3 Sep 2009 18:22:21 +0530 From: Kapil Gupta To: "rxtx at qbang.org" Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059 at NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset="us-ascii" Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: ------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx End of Rxtx Digest, Vol 25, Issue 3 *********************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From ilkka at myller.com Thu Sep 3 11:17:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 3 Sep 2009 20:17:27 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <4520677F-E8F0-46F5-B4AD-3AD3A7C2AED3@myller.com> Hi Kapil, The code is incomplete and I did not find anything I could to test/ debug with this. I also tried to find the actual serial port opening, but found only a call to missing method which creates the SerialPort object (?): serialPort = getSerialPortConnection( COMPort, this.readEvent.getDeviceName(), SerialCommConfig.DEVICE1[SerialCommConfig.TIMEOUT], SerialCommConfig.DEVICE1[SerialCommConfig.BAUDRATE], SerialCommConfig.DEVICE1[SerialCommConfig.DATABITS], SerialCommConfig.DEVICE1[SerialCommConfig.STOPBITS], SerialCommConfig.DEVICE1[SerialCommConfig.PARITY] ); The class SerialCommConfig is missing too. If this is a part of the actual code you are using, please note that you are not actually closing the serial port. The call to close() method is commented out: try { // serialPort.close(); } catch (Exception ex) { ex.printStackTrace(); } Re-opening of the serial port wont work if you haven't properly closed it first. -- I > > I am using RXTX on Macintosh to communicate to my device. First time > the device responds well but on second time, it hangs on > COMPort.open (name, timeout). > > I have attached the source code in a file. Please help me. > > Thanks & Best Regards, > Kapil -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorton at intellimec.com Thu Sep 3 11:37:55 2009 From: dmorton at intellimec.com (Daniel Morton) Date: Thu, 3 Sep 2009 13:37:55 -0400 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. (I haven't tried previous version though). Daniel Morton Java/J2EE Developer Tel +1 519.745.8887 x4331 Email dmorton at intellimec.com www.intellimec.com | www.iLane.com | www.drivesync.com Intelligent Mechatronic Systems Inc. 435 King Street North Waterloo, ON N2J 2Z5 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s Sent: Thursday, September 03, 2009 4:50 AM To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. From alexanderkiel at gmx.net Fri Sep 4 02:29:15 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 10:29:15 +0200 Subject: [Rxtx] Official Javadoc Location Message-ID: <1252052955.4025.80.camel@T61-KIEL> Hi List, I wasn't able to find an official location of RXTX Javadoc accessible over HTTP. Maybe someone can link me to it. If there is no such location, I would like to see one. I like to link from my own Javadoc to such a location. Thanks Alexander - e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:19:25 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:19:25 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> Message-ID: <1252055965.4025.84.camel@T61-KIEL> Hi Michael, thanks for the pointer. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 09:48 +0100, Michael Tandy wrote: > RxTx javadoc: http://users.frii.com/jarvi/rxtx/doc/index.html > Javax interface RxTx duplicates javadoc: > http://java.sun.com/products/javacomm/reference/api/index.html > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:22:14 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:22:14 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> Message-ID: <1252056134.4025.87.camel@T61-KIEL> Hi Eike, thanks, but I need a direct package pointer so that Javadoc will link the gnu.io packages automatically to the right location. Michael has pointed me to http://users.frii.com/jarvi/rxtx/doc/index.html which has the gnu.io packages. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 11:04 +0200, Eike Hinderk J?rrens wrote: > Hi Alexander, > it seems to me that RXTX is implementing this API: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Kind regards, > Eike > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kjetilos at gmail.com Fri Sep 4 03:43:41 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 11:43:41 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> Message-ID: <7a803d460909040243ke4449ecucbe2cd8b15761746@mail.gmail.com> Hi Daniel, This is interesting, what type of application are you making? Is there a lot of signaling on different COM ports at the same time in your application? In our application we have 11 devices connected to different COM ports, 9 of these are in active use when the application is running. I'm wondering how to use the RXTX library version 2.1.7 in this scenario without causing it to crash. After adding more signaling on the COM ports in our application we have now experienced other crashes and it is natural to think that it has something to do with our way of using RXTX from several threads at the same time. So my question is are there any methods like read/write/flush/close that are not thread safe and should be handled with care? And similarly is the RXTXPort.SerialInputStream and RXTXPort.SerialOutputStream thread safe? 2009/9/3 Daniel Morton : > I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. ?(I haven't tried previous version though). > > Daniel Morton > Java/J2EE Developer > > Tel ? ?+1 519.745.8887 x4331 > Email ? ?dmorton at intellimec.com > > > www.intellimec.com ?| ?www.iLane.com ?| ?www.drivesync.com > > > > Intelligent Mechatronic Systems Inc. > 435 King Street North Waterloo, ON N2J 2Z5 > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s > Sent: Thursday, September 03, 2009 4:50 AM > To: rxtx at qbang.org > Subject: [Rxtx] RXTX multiple crashes > > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x7d0d] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0ce75800): ?JavaThread "Y Worker" daemon > [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 > > Registers: > EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 > ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 > EIP=0x10007d0d, EFLAGS=0x00010202 > > Top of Stack: (sp=0x0d7ff6d8) > 0x0d7ff6d8: ? 0d7ff700 00000000 00000000 00000000 > 0x0d7ff6e8: ? 02a2eae8 00000123 00002958 0d7ff718 > 0x0d7ff6f8: ? 7c830887 7c90d28a 7c8664b5 00000e2c > 0x0d7ff708: ? 00002958 00000000 00000000 7c90cffa > 0x0d7ff718: ? 7c809bdb 00002958 0d7ff758 00000e40 > 0x0d7ff728: ? 00002958 02bd0468 0ce75800 080e4ee0 > 0x0d7ff738: ? 00000000 00000000 00000000 00000000 > 0x0d7ff748: ? 00000000 00000000 00000014 7c90d09a > > Instructions: (pc=0x10007d0d) > 0x10007cfd: ? 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 > 0x10007d0d: ? 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 > > > Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x7d0d] > J ?gnu.io.RXTXPort.nativeDrain(Z)Z > J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > ... > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x9c55] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0cddf400): ?JavaThread "XXX Worker" daemon > [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 > > Registers: > EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 > ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 > EIP=0x10009c55, EFLAGS=0x00010206 > > Top of Stack: (sp=0x0bb8f830) > 0x0bb8f830: ? 00000000 00000000 c0000005 00000000 > 0x0bb8f840: ? 00000000 00f1f0a5 00000002 00000000 > 0x0bb8f850: ? 003a0100 0001003f 0bb8fb20 0b9ff918 > 0x0bb8f860: ? 00000000 00000000 0bb8fb68 0bb8fb20 > 0x0bb8f870: ? 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 > 0x0bb8f880: ? 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 > 0x0bb8f890: ? 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 > 0x0bb8f8a0: ? 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 > > Instructions: (pc=0x10009c55) > 0x10009c45: ? 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff > 0x10009c55: ? 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 > > > Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x9c55] > C ?[rxtxSerial.dll+0xa05e] > J ?gnu.io.RXTXPort.readByte()I > J ?gnu.io.RXTXPort$SerialInputStream.read()I > J ?java.io.FilterInputStream.read()I > ... > > -- > Kjetil ?ster?s > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kjetil ?ster?s From tjarvi at qbang.org Fri Sep 4 06:00:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Sep 2009 06:00:40 -0600 (MDT) Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x7d0d] > J gnu.io.RXTXPort.nativeDrain(Z)Z > J gnu.io.RXTXPort$SerialOutputStream.flush()V > Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x9c55] > C [rxtxSerial.dll+0xa05e] > J gnu.io.RXTXPort.readByte()I > J gnu.io.RXTXPort$SerialInputStream.read()I RXTX 2.1-7 has concurrency issues that will show upon multicore systems. These should be resolved in the 2.2 pre release. A user application could synchronize the read/write/open/close calls while using 2.1 to avoid the concurrency issue. The flush is probably following a write while the readByte is coming from read(byte b). The bugs existed in rxtx for a long time. I assume changes in the JVM and the presence of multicore systems exposed the issues. -- Trent Jarvi tjarvi at qbang.org From kjetilos at gmail.com Fri Sep 4 06:33:33 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 14:33:33 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <7a803d460909040533n1caf240y8168477a578bc45c@mail.gmail.com> Den 4. september 2009 14.00 skrev Trent Jarvi f?lgende: > > > On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > >> Hi >> >> We are using RXTX version 2.1.7 actively and lately we are having some >> issues with the RXTX library crashing. We are running a windows xp >> system with multiple COM ports where each COM port have a serial >> device connected. Lately we have increased the amount of signaling >> done over the COM ports and we are experiencing several odd crashes. I >> tried to search the mailinglist for something similar but was unable >> to find anything. At one time the RXTX crashed in the >> gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the >> gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack >> traces if someone is interested in having a look. Has anyone seen the >> same crashes? and does anyone know what can cause such crash? >> >> >> Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x7d0d] >> J ?gnu.io.RXTXPort.nativeDrain(Z)Z >> J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > >> Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x9c55] >> C ?[rxtxSerial.dll+0xa05e] >> J ?gnu.io.RXTXPort.readByte()I >> J ?gnu.io.RXTXPort$SerialInputStream.read()I > > > RXTX 2.1-7 has concurrency issues that will show upon multicore systems. > These should be resolved in the 2.2 pre release. ?A user application could > synchronize the read/write/open/close calls while using 2.1 to avoid the > concurrency issue. > > The flush is probably following a write while the readByte is coming from > read(byte b). > > The bugs existed in rxtx for a long time. ?I assume changes in the JVM and > the presence of multicore systems exposed the issues. > Ok, so we should look more into using a newer version of RXTX. The current version from the webpage is 2.2pre2, what is the stability status of this version. Is it good enough for use in a production environment? -- Kjetil ?ster?s From martinezrodolfo at gmail.com Fri Sep 4 13:39:57 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Fri, 4 Sep 2009 15:09:57 -0430 Subject: [Rxtx] Problem with data available event Message-ID: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Hello list members. I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a serial port USB adapter to communicate with an electronical inmunoassay analyzer. The program works porperly with one model of the analyzer series. It defines a protocol which every message sent should be replied with an ACK in order to continue with the communication. Now we are trying to communicate with another model of the same brand and series wich in theory should be much of the same of what was previously done. Unfortunately, that is not the case. The problem with this connection is that it never fires the Data Available serial port event. Is like if nothing was being received in the input stream. The following code always prints zero when the equipment should be transmitting. ----------------------- beginning of sample code ---------------------------------- SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", 10000); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); int len = 0; byte[] readBuffer = new byte[8]; while (true) { len = in.read(readBuffer); System.out.println(len); writer.writeACK(); // writing ACK to analyzer } ----------------------- end of sample code ------------------------------------------ We know that the analyzer is transmitting because HyperTerminal does shows the proper output. In fact, after running the above code and connecting via Hyperterminal all data is received in one block. Is like the data sent from the analyzer is being held somewhere in the way. Sniffing at the serial port, noticed that IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this helps to find what might be wrong or not, but here they are: On Hyperterminal: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 XonLimit:80 XoffLimit:200 On Java: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 XonLimit:0 XoffLimit:0 Thanks in advance for your help. Rodolfo M From ilkka at myller.com Sat Sep 5 04:36:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 5 Sep 2009 13:36:27 +0300 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <121198EE-65A4-463B-ACC7-29FFB9855B2C@myller.com> Hi Rodolfo, By default RXTX does not enable any flow control for the serial port. Please check what flow control you have active in HyperTerminal when you are able to receive data and then use the same flow control with RXTX serial port: serialPort.setFlowControlMode(int flowcontrol); Possible flowcontrol flags are (from SerialPort class) FLOWCONTROL_NONE FLOWCONTROL_RTSCTS_IN FLOWCONTROL_RTSCTS_OUT FLOWCONTROL_XONXOFF_IN FLOWCONTROL_XONXOFF_OUT For example, you can try enabling RTS/CTS hardware flow control. Note the bitwise OR operator ' | ': serialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Also if your device requires RTS/CTS flow control make sure you have fully connected serial cable (not just RX, TX, GND for example, but also RTS, CTS, DTR). One thing you might want to check is the state of DTR (Data Terminal Ready). Some devices wait for the DTR signal before they send any data. You can enable or disable DTR signal (high/low) with: serialPort.setDTR( boolean state ); -- I > Hello list members. > > I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a > serial port USB adapter to communicate with an electronical > inmunoassay analyzer. The program works porperly with one model of the > analyzer series. It defines a protocol which every message sent should > be replied with an ACK in order to continue with the communication. > Now we are trying to communicate with another model of the same brand > and series wich in theory should be much of the same of what was > previously done. Unfortunately, that is not the case. The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. > > ----------------------- beginning of sample code > ---------------------------------- > SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", > 10000); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > InputStream in = serialPort.getInputStream(); > OutputStream out = serialPort.getOutputStream(); > > int len = 0; > byte[] readBuffer = new byte[8]; > while (true) { > len = in.read(readBuffer); > System.out.println(len); > > writer.writeACK(); // writing ACK to analyzer > } > ----------------------- end of sample code > ------------------------------------------ > > We know that the analyzer is transmitting because HyperTerminal does > shows the proper output. In fact, after running the above code and > connecting via Hyperterminal all data is received in one block. Is > like the data sent from the analyzer is being held somewhere in the > way. Sniffing at the serial port, noticed that > IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this > helps to find what might be wrong or not, but here they are: > > On Hyperterminal: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 > XonLimit:80 XoffLimit:200 > > On Java: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 > XonLimit:0 XoffLimit:0 > > > Thanks in advance for your help. > Rodolfo M > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.weber99 at gmx.net Sun Sep 6 13:51:12 2009 From: karl.weber99 at gmx.net (Karl Weber) Date: Sun, 6 Sep 2009 21:51:12 +0200 Subject: [Rxtx] Cannot create lock file Message-ID: <200909062151.12228.karl.weber99@gmx.net> Hi, I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an opensuse repository as well as from the homepage of the rxtx project. I have already added the user to the group uucp, however, it does not have any effect. What else do I have to do to make it work? (It does work with user root, though.) The error message is: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL Thanks in advance, Karl From tjarvi at qbang.org Sun Sep 6 13:51:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 6 Sep 2009 13:51:42 -0600 (MDT) Subject: [Rxtx] Cannot create lock file In-Reply-To: <200909062151.12228.karl.weber99@gmx.net> References: <200909062151.12228.karl.weber99@gmx.net> Message-ID: On Sun, 6 Sep 2009, Karl Weber wrote: > Hi, > > I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an > opensuse repository as well as from the homepage of the rxtx project. > > I have already added the user to the group uucp, however, it does not have > any effect. What else do I have to do to make it work? (It does work with > user root, though.) > > The error message is: > > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to > create lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > > Thanks in advance, Karl Look at the group that owns /var/lock with ls -ld /var/lock The following should work as a user when they are in the correct group: touch /var/lock/test && rm -f /var/lock/test -- Trent Jarvi tjarvi at qbang.org From Luca.Catoni at sysdat.it Mon Sep 7 06:32:42 2009 From: Luca.Catoni at sysdat.it (Luca Catoni) Date: Mon, 7 Sep 2009 14:32:42 +0200 Subject: [Rxtx] time-out implementation Message-ID: I need to implement a simple timer class to manage time-out in my RS-232 serial communication with a remote device using the rxtx library. The functions that the timer should have are start(), and reset() and start() method must throw an exception (TimeoutException) when it expires. I am not an expert in concurrent programming and I do not have much knowledge on threads. myTimer.setExpirationTime(myvalue); ? public void serialEvent(SerialPortEvent event) { if (event.getEventType() == SerialPortEvent.OUTPUT_BUFFER_EMPTY) { // transmission ? out.write(?); try{ myTimer.start(); }catch(TimeoutException te){ myTimer.reset(); ? } ? if (event.getEventType() == SerialPortEvent.DATA_AVAILABLE) { // receiving in.read(?); if (mycondition){ myTimer.stop();//ok, timer NOT expired myTimer.reset();//now I can call start() method again in //transmission to restart my timer when I //have to transmit next data } Can anyone help me to implement the class MyTimer? thanks in advance. -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Mon Sep 7 06:49:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Mon, 7 Sep 2009 18:19:24 +0530 Subject: [Rxtx] 2.2Pre + MacMini+ Deadlock while second time port Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E22FB6F@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, Please find the updated code (close call was commented by mistake). This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From michael.erskine at ketech.com Mon Sep 7 09:13:03 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 7 Sep 2009 16:13:03 +0100 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Rodolfo Mart?nez > Subject: [Rxtx] Problem with data available event > The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. Hi Rodolfo, The sample code you provided doesn't implement or register any event listeners. Regards, Michael Erskine. From martinezrodolfo at gmail.com Mon Sep 7 10:21:22 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Mon, 7 Sep 2009 11:51:22 -0430 Subject: [Rxtx] Problem with data available event In-Reply-To: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> Message-ID: <30eacee0909070921l7f285765ue2c661963183fd2b@mail.gmail.com> On Mon, Sep 7, 2009 at 10:43 AM, Michael Erskine wrote: > Hi Rodolfo, > The sample code you provided doesn't implement or register any event listeners. > > Regards, > Michael Erskine. Hi Michael, I didn't write the event listeners declaration on the sample code for simplicity, but I do implement them on my real code. I should have mentioned it on the sample code anyway... my bad. I haven't had access to the device I'm trying to connect, but tomorrow will. And hope that with the explanation of Ilkka Myller will succeed this time. Thanks for your attention. Rodolfo M From ajmas at sympatico.ca Mon Sep 7 16:58:13 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 7 Sep 2009 18:58:13 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" I noticed in the page you posted posted you indicated that you patched two files. Did you submit the changes to Jarvi, so they could be included in the main code branch? Andr? From tjarvi at qbang.org Mon Sep 7 16:57:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Sep 2009 16:57:53 -0600 (MDT) Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On Mon, 7 Sep 2009, Andre-John Mas wrote: > > On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > >> Sorry, my rudeness was not intentional (a typo). >> Lets try again.. ;) >> >> "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > I noticed in the page you posted posted you indicated that you patched two > files. Did you submit the changes to Jarvi, so they could be included in the > main code branch? > Hi Andr? Ilkka is working with us to get changes in. I'm not sure about those two patches which may already be in CVS. I'll let him answer that. I've given him write access to CVS and asked him to cc the list non whitespace changes when they are ready. Right now he is asking questions off the list regarding cleaning up the Mac and w32 build files. -- Trent Jarvi tjarvi at qbang.org From nsp25 at cornell.edu Mon Sep 7 21:17:45 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Mon, 7 Sep 2009 23:17:45 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: (Sorry if this is a double post, but I sent my original message without subscribing, and since this is an urgent problem, I thought I'd resend after subscribing to bypass the moderator limbo zone) Hi all, I've asked my question on StackOverflow already, so rather than copy-paste the question here, I'd like to redirect you there . Short version, I am no longer able to receive anything over RS-232 with RXTX, but other programs work fine. I'm definitely sending things, because when I connect with a different program, all the responses to the commands I sent via RXTX arrive all at once. Everything was fine in the spring, so what could have happened? Windows update? -Nate -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.j.tandy at warwick.ac.uk Tue Sep 8 01:30:48 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Tue, 8 Sep 2009 08:30:48 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> OK, so: 1. It worked in spring but has stopped doing so and 2. The data all arrives at once when you start hyperterminal. Is it possible you're using a different serial cable to connect to the device, compared to the one you were using in spring? If so, the issue might be hardware flow control - that is, your device might be buffering data because it can't transmit it until your computer sets 'DTR' or 'RTS' or something like that. One way of bypassing hardware flow control is by using cables which cross over certain wires so that the right signals are always being sent; it's possible your old cable had these connections but your current cable doesn't have them. If you can find the old cable, you could put it back in and see if that fixes things? 2009/9/8 Nathaniel S. Parsons : > (Sorry if this is a double post, but I sent my original message without > subscribing, and since this is an urgent problem, I thought I'd resend after > subscribing to bypass the moderator limbo zone) > > Hi all, > > I've asked my question on StackOverflow already, so rather than copy-paste > the question here, I'd like to redirect you there. > > Short version, I am no longer able to receive anything over RS-232 with > RXTX, but other programs work fine. I'm definitely sending things, because > when I connect with a different program, all the responses to the commands I > sent via RXTX arrive all at once. > > Everything was fine in the spring, so what could have happened? Windows > update? > > -Nate > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Tue Sep 8 01:50:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 8 Sep 2009 10:50:33 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <111FEC9A-26BA-435C-BABC-314C7E4F23E5@myller.com> Hi all, Patches applied to the 2.1.7 binaries distributed by Robert Harder (http://iharder.sourceforge.net/current/java/ ) are already in the 2.2. Actually in 2.2 the issue with integer types handling seems to be fixed even more extensively than that single patch to 2.1.7 originally did. And yes, Trent has granted me CVS commit access. Thank you. First thing I'm going to focus on is the code quality and clean up: unused variables, invalid pointer usage etc.. Most of this just causing compile warnings - some harmless and some have potential for causing runtime problems. Instead of just blindly committing new changes to CVS, I've been discussing with Trent about the way things have been done in the RXTX CVS before. (how to handle white space patches, what needs to be discussed with the list first, proper locations for new files/ directories/subprojects, "the way things are done in RXTX"). But patches are coming and bugs will be fixed. I hope everyone will continue to submit the bugs they discover to this mailing list. Most important thing is to provide enough info (code;) so that the issue can be duplicated and eventually fixed. -- I > > > On Mon, 7 Sep 2009, Andre-John Mas wrote: >> >> I noticed in the page you posted posted you indicated that you >> patched two files. Did you submit the changes to Jarvi, so they >> could be included in the main code branch? >> > > Ilkka is working with us to get changes in. I'm not sure about > those two patches which may already be in CVS. I'll let him answer > that. > > I've given him write access to CVS and asked him to cc the list non > whitespace changes when they are ready. Right now he is asking > questions off the list regarding cleaning up the Mac and w32 build > files. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 15:35:19 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 17:35:19 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: Thanks for the response. I'll try to get to the electronics store tomorrow to get more serial cables, even if it isn't the problem. I am using a different serial cable than I was in the spring. It's actually a Male/Female cable with a female-female adapter since the old cables aren't around anymore. The hardware's manual says nothing except to use a "Straight cable" but I figured that if it worked in HyperTerminal, it should work in RXTX, right? Anyways, I've also noticed some things that are different between HyperTerminal, RXTX, and a separate program I found that communicates with the device (but doesn't do what I want, which is why I'm rolling my own program) HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and DTR indicators are green Other program - not sure what settings it thinks it's using, but only SPM's RTS indicator is green RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators are on. >From Serial Port Monitor's help files (paraphrased): the indicators display the state of the serial control lines RTS - Request To Send CTS - Clear To Send DTR - Data Terminal Ready Could this be related to the problem? -Nate On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > OK, so: > > 1. It worked in spring but has stopped doing so and > 2. The data all arrives at once when you start hyperterminal. > > Is it possible you're using a different serial cable to connect to the > device, compared to the one you were using in spring? > > If so, the issue might be hardware flow control - that is, your device > might be buffering data because it can't transmit it until your > computer sets 'DTR' or 'RTS' or something like that. > > One way of bypassing hardware flow control is by using cables which > cross over certain wires so that the right signals are always being > sent; it's possible your old cable had these connections but your > current cable doesn't have them. If you can find the old cable, you > could put it back in and see if that fixes things? > > > 2009/9/8 Nathaniel S. Parsons : > > (Sorry if this is a double post, but I sent my original message without > > subscribing, and since this is an urgent problem, I thought I'd resend > after > > subscribing to bypass the moderator limbo zone) > > > > Hi all, > > > > I've asked my question on StackOverflow already, so rather than > copy-paste > > the question here, I'd like to redirect you there. > > > > Short version, I am no longer able to receive anything over RS-232 with > > RXTX, but other programs work fine. I'm definitely sending things, > because > > when I connect with a different program, all the responses to the > commands I > > sent via RXTX arrive all at once. > > > > Everything was fine in the spring, so what could have happened? Windows > > update? > > > > -Nate > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 18:57:58 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 20:57:58 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: I added a call to setRTS() but nothing changed in Serial Port Monitor, no matter what the argument was. Is this a bug, or did I call the wrong function? I tried to find the c code behind this function, and I think I found it in rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong to me. Am I looking at the right function or is the problem somewhere else? -Nate On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons wrote: > Thanks for the response. I'll try to get to the electronics store tomorrow > to get more serial cables, even if it isn't the problem. > > I am using a different serial cable than I was in the spring. It's actually > a Male/Female cable with a female-female adapter since the old cables aren't > around anymore. The hardware's manual says nothing except to use a "Straight > cable" but I figured that if it worked in HyperTerminal, it should work in > RXTX, right? > > Anyways, I've also noticed some things that are different between > HyperTerminal, RXTX, and a separate program I found that communicates with > the device (but doesn't do what I want, which is why I'm rolling my own > program) > > HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and > DTR indicators are green > Other program - not sure what settings it thinks it's using, but only SPM's > RTS indicator is green > RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators > are on. > > From Serial Port Monitor's help files (paraphrased): the indicators display > the state of the serial control lines > > RTS - Request To Send > CTS - Clear To Send > DTR - Data Terminal Ready > > Could this be related to the problem? > > -Nate > > > On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > >> OK, so: >> >> 1. It worked in spring but has stopped doing so and >> 2. The data all arrives at once when you start hyperterminal. >> >> Is it possible you're using a different serial cable to connect to the >> device, compared to the one you were using in spring? >> >> If so, the issue might be hardware flow control - that is, your device >> might be buffering data because it can't transmit it until your >> computer sets 'DTR' or 'RTS' or something like that. >> >> One way of bypassing hardware flow control is by using cables which >> cross over certain wires so that the right signals are always being >> sent; it's possible your old cable had these connections but your >> current cable doesn't have them. If you can find the old cable, you >> could put it back in and see if that fixes things? >> >> >> 2009/9/8 Nathaniel S. Parsons : >> > (Sorry if this is a double post, but I sent my original message without >> > subscribing, and since this is an urgent problem, I thought I'd resend >> after >> > subscribing to bypass the moderator limbo zone) >> > >> > Hi all, >> > >> > I've asked my question on StackOverflow already, so rather than >> copy-paste >> > the question here, I'd like to redirect you there. >> > >> > Short version, I am no longer able to receive anything over RS-232 with >> > RXTX, but other programs work fine. I'm definitely sending things, >> because >> > when I connect with a different program, all the responses to the >> commands I >> > sent via RXTX arrive all at once. >> > >> > Everything was fine in the spring, so what could have happened? Windows >> > update? >> > >> > -Nate >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Tue Sep 8 21:54:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 21:54:26 -0600 (MDT) Subject: [Rxtx] rxtx is moving to the clouds Message-ID: rxtx is moving onto a cloud server. You may notice short outages as things move around. So far the following is done. http://rxtx.qbang.org (will redirect rxtx.org there for 2.2) http://bugzilla.qbang.org (bugs) The mail-list is tomorrow night. CVS and FTP will be last. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 8 22:03:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 22:03:26 -0600 (MDT) Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: On Tue, 8 Sep 2009, Nathaniel S. Parsons wrote: > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? Hi Nathaniel, That depends upon what you are running. WinCE is for embedded windows. The Windows source is in src/termios.c (called from src/SerialImp.c). -- Trent Jarvi tjarvi at qbang.org From m.j.tandy at warwick.ac.uk Wed Sep 9 03:27:10 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 10:27:10 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> I had a similar problem a while ago - hardware that would work with Hyperterminal but not with Rxtx. I don't know if this is a bug in RxTx or not - I tried to find where in the RxTx source code those functions are actually implemented - I got as far as the ioctl function in termios.c, where the TIOCMSET case sets the MSR byte in the termios struct, but I can't figure out where that gets written to the dcb struct's fDtrControl dword. It could be a bug, or it could just be me missing something. In any case, at the time I had this problem I wasn't equipped to debug RxTx so instead I created a special cable to satisfy the hardware's flow control while leaving the data connection straight through. Here's how I connected it: At the female end of the cable (i.e. the hardware I was connecting to) I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. I connected the ground and data pins straight through - that is, pin 5 female end to pin 5 male end, pin 2 female end to pin 2 male end, pin 3 female end to pin 3 male end. Anyway, using that cable bypassed the hardware's flow control, and got RxTx working just as well as HyperTerminal - although I slowed down my communication to make sure I didn't encounter a situation where the flow control would have come into effect, as I had bypassed it! Hope that helps. 2009/9/9 Nathaniel S. Parsons : > I added a call to setRTS() but nothing changed in Serial Port Monitor, no > matter what the argument was. Is this a bug, or did I call the wrong > function? > > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? > > -Nate > > On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > wrote: >> >> Thanks for the response. I'll try to get to the electronics store tomorrow >> to get more serial cables, even if it isn't the problem. >> >> I am using a different serial cable than I was in the spring. It's >> actually a Male/Female cable with a female-female adapter since the old >> cables aren't around anymore. The hardware's manual says nothing except to >> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >> should work in RXTX, right? >> >> Anyways, I've also noticed some things that are different between >> HyperTerminal, RXTX, and a separate program I found that communicates with >> the device (but doesn't do what I want, which is why I'm rolling my own >> program) >> >> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >> DTR indicators are green >> Other program - not sure what settings it thinks it's using, but only >> SPM's RTS indicator is green >> RXTX - no matter what flow control I set, only SPM's CTS and DTR >> indicators are on. >> >> From Serial Port Monitor's help files (paraphrased): the indicators >> display the state of the serial control lines >> >> RTS - Request To Send >> CTS - Clear To Send >> DTR - Data Terminal Ready >> >> Could this be related to the problem? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> wrote: >>> >>> OK, so: >>> >>> 1. It worked in spring but has stopped doing so and >>> 2. The data all arrives at once when you start hyperterminal. >>> >>> Is it possible you're using a different serial cable to connect to the >>> device, compared to the one you were using in spring? >>> >>> If so, the issue might be hardware flow control - that is, your device >>> might be buffering data because it can't transmit it until your >>> computer sets 'DTR' or 'RTS' or something like that. >>> >>> One way of bypassing hardware flow control is by using cables which >>> cross over certain wires so that the right signals are always being >>> sent; it's possible your old cable had these connections but your >>> current cable doesn't have them. If you can find the old cable, you >>> could put it back in and see if that fixes things? >>> >>> >>> 2009/9/8 Nathaniel S. Parsons : >>> > (Sorry if this is a double post, but I sent my original message without >>> > subscribing, and since this is an urgent problem, I thought I'd resend >>> > after >>> > subscribing to bypass the moderator limbo zone) >>> > >>> > Hi all, >>> > >>> > I've asked my question on StackOverflow already, so rather than >>> > copy-paste >>> > the question here, I'd like to redirect you there. >>> > >>> > Short version, I am no longer able to receive anything over RS-232 with >>> > RXTX, but other programs work fine. I'm definitely sending things, >>> > because >>> > when I connect with a different program, all the responses to the >>> > commands I >>> > sent via RXTX arrive all at once. >>> > >>> > Everything was fine in the spring, so what could have happened? Windows >>> > update? >>> > >>> > -Nate >>> > >>> > _______________________________________________ >>> > Rxtx mailing list >>> > Rxtx at qbang.org >>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>> > >>> > >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Wed Sep 9 03:54:45 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 12:54:45 +0300 Subject: [Rxtx] Xcode 3.x project available in CVS Message-ID: Hi everyone, I've just committed Apple Xcode 3.x (preferably 3.2) compatible project to CVS. The project can be used to develop and build Mac OS X 10.5+ compatible Universal Binary JNI library and RXTXcomm.jar. It's does not have dependencies to existing Autotools based build scripts - only standard Xcode installation is required. The older Xcode 2.x project is still there, but please note that it's not compatible with newer Xcode versions due to its dependency to deprecated Jam build system. The new project is available in rxtx-devel/MACOSX_IDE/Xcode3 How to get the source code from CVS: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Latest Xcode can be downloaded from Apple: http://developer.apple.com/technology/xcode.html -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 05:07:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 14:07:05 +0300 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: Nathaniel, I agree with Michael that your issue is probably with incorrect hardware flow control (RTS/CTS + possibly DTR/DSR). With RXTX you can do things manually, automatically or by mixing both ways. RXTX is "low-level" enough to let developer make those decisions. Which is proper. Automatic hardware flow-control: If you want to do automatic RTS/CTS flow control in both directions (from and to PC) you must set: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Note that you must combine flow control flags with bitwise OR ( ' | ' ) Manual: If you want to bypass all flow controls signals, or handle them manually you must set: setFlowControlMode( SerialPort.FLOWCONTROL_NONE ); In manual mode, you must manually handle controlling signals from PC and reading flow control signals from by the device: RTS - Request To Send -- setRTS() method can used to set this CTS - Clear To Send -- isCTS() method can be used to read this For example, it is entirely possible to manually implement normal RTS/ CTS flow control with RXTX without relying on low-level automatic implementation. Mixed: You can also configure serial port to handle RTS/CTS automatically in only one direction, then you must set one of: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN ); or setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_OUT ); Then you can either ignore or implement manually the flow control scheme in the other direction. DTR and DSR: These are not officially flow control signals, but might affect external devices (disable, standby etc.). Use and meaning of these depends on the device. DTR - Data Terminal Ready -- setDTR() method DSR - Data Set Ready -- setDSR() method CTS/RTS standards: Please note that there are two standard ways RTS/CTS flow control is done (depends on the device): asymmetric (RS-232) symmetric (RS-232-E / TIA-232-E) For more info see: http://en.wikipedia.org/wiki/RS232#RTS.2FCTS_handshaking Some devices may even use RTS/CTS to some other non-standard purpose. With those devices, enabling automatic RTS/CTS could cause very strange behaviour as they clearly require manual control of CTS/RTS. ---- As far as I know, RXTX properly controls all these signals all the way to actual RS232 pins - unless there is a new platform incompatibility bug that I'm not aware of;) Mostly it's just wrong combination and/or usage of these additional signals that cause problems receiving or sending. And the only solution is to really *know* how your device wants these signals handled - and then code your RXTX application accordingly. Creating non-standard cable is not the right solution in my opinion. Unfortunately some applications (like HyperTerminal for example) might hit more or less accidentally to the right combination of RTS/CTS/DTR/ DSR usage and make RXTX look bad in comparison. While all RXTX does by default is - well - nothing. It gives full control the developer. -- I > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port >> Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I >> found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't >> look wrong >> to me. Am I looking at the right function or is the problem >> somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > > >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store >>> tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since >>> the old >>> cables aren't around anymore. The hardware's manual says nothing >>> except to >>> use a "Straight cable" but I figured that if it worked in >>> HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that >>> communicates with >>> the device (but doesn't do what I want, which is why I'm rolling >>> my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's >>> RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but >>> only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> > >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect >>>> to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your >>>> device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>>> (Sorry if this is a double post, but I sent my original message >>>>> without >>>>> subscribing, and since this is an urgent problem, I thought I'd >>>>> resend >>>>> after >>>>> subscribing to bypass the moderator limbo zone) >>>>> >>>>> Hi all, >>>>> >>>>> I've asked my question on StackOverflow already, so rather than >>>>> copy-paste >>>>> the question here, I'd like to redirect you there. >>>>> >>>>> Short version, I am no longer able to receive anything over >>>>> RS-232 with >>>>> RXTX, but other programs work fine. I'm definitely sending things, >>>>> because >>>>> when I connect with a different program, all the responses to the >>>>> commands I >>>>> sent via RXTX arrive all at once. >>>>> >>>>> Everything was fine in the spring, so what could have happened? >>>>> Windows >>>>> update? >>>>> >>>>> -Nate >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 06:11:11 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 15:11:11 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings Message-ID: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Hi, Summary: Patch includes multiple minor code quality improvements and also fixes one possible null pointer segfault on Mac. After this patch, compilation on Mac OS X is error/warning free even with gcc -Wall setting. I'll submit more code quality patches later that focus more on linux/ win/java. Fixes: Code quality: - First level parentheses around assignment used as while-loop truth value - Some printf formats not a string literals and including no format arguments Invalid null pointer usage: - Mac: IOMasterPort was called with (int)NULL which does not always resolve to segfault safe value. Corrected to use MACH_PORT_NULL instead. Patch: The patch is against CVS head (@2009/09/09). Attached patch file is in 'cvs diff -up' format. I'll commit this patch to the CVS later this week if there are no objections. Feel free to comment. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090909.patch Type: application/octet-stream Size: 1966 bytes Desc: not available URL: From m.j.tandy at warwick.ac.uk Wed Sep 9 06:57:55 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 13:57:55 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> OK, I just ran a test with my copy of RxTx and the following program: import gnu.io.*; public class SerialTest { public static void main(String[] args) { try { CommPortIdentifier portid = CommPortIdentifier.getPortIdentifier("COM9"); SerialPort serialPort = (SerialPort)portid.open("Serial port DTR/RTS test", 1000); serialPort.setSerialPortParams(4800, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.disableReceiveTimeout(); for (int i=0 ; i<60 ; i++) { serialPort.setDTR(true); serialPort.setRTS(true); Thread.sleep(1000); serialPort.setDTR(false); serialPort.setRTS(false); Thread.sleep(1000); } } catch (Exception e) { e.printStackTrace(); System.exit(1); } System.exit(0); } } I'm using a USB-serial converter (Prolific PL-2303) and I used a multimeter to check that my DTR and RTS pins were both toggling, and they were - between +7 and -6.4 volts. In other words, on the computer I'm using at the moment, with the version of RxTx I'm using at the moment, setDTR and setRTS both seem to work fine. I don't know if it's worth it for you to perform the same test. I gather there are several different configurations for hardware flow control, (DTR/DSR handshaking as well as RTS/CTS handshaking, handshaking for half-duplex operation, and similar) so the cable that worked for me might still be worth a try. 2009/9/9 Michael Tandy : > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong >> to me. Am I looking at the right function or is the problem somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since the old >>> cables aren't around anymore. The hardware's manual says nothing except to >>> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that communicates with >>> the device (but doesn't do what I want, which is why I'm rolling my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>> > (Sorry if this is a double post, but I sent my original message without >>>> > subscribing, and since this is an urgent problem, I thought I'd resend >>>> > after >>>> > subscribing to bypass the moderator limbo zone) >>>> > >>>> > Hi all, >>>> > >>>> > I've asked my question on StackOverflow already, so rather than >>>> > copy-paste >>>> > the question here, I'd like to redirect you there. >>>> > >>>> > Short version, I am no longer able to receive anything over RS-232 with >>>> > RXTX, but other programs work fine. I'm definitely sending things, >>>> > because >>>> > when I connect with a different program, all the responses to the >>>> > commands I >>>> > sent via RXTX arrive all at once. >>>> > >>>> > Everything was fine in the spring, so what could have happened? Windows >>>> > update? >>>> > >>>> > -Nate >>>> > >>>> > _______________________________________________ >>>> > Rxtx mailing list >>>> > Rxtx at qbang.org >>>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>>> > >>>> > >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > From david at attglobal.net Wed Sep 9 09:17:27 2009 From: david at attglobal.net (David Schmidt) Date: Wed, 09 Sep 2009 11:17:27 -0400 Subject: [Rxtx] 2.2 Release plans Message-ID: <4AA7C707.5060802@attglobal.net> I'm holding off releasing an update to my project (adtpro.sourceforge.net) to support OSX Snow Leopard because I'd like to ship an "official" build of rxtx 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for toggling a port off). CVS is looking great on OSX - thanks to all who have been hard at work on that. I wish there were just one more update - Pre3? :-) My question... If I wanted to make a release in, say, a week... would it pay to wait for rxtx, or should I plan to build and ship a local build of 2.2 out of CVS myself? - David Schmidt From tjarvi at qbang.org Wed Sep 9 19:14:29 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:14:29 -0600 (MDT) Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: On Wed, 9 Sep 2009, Ilkka Myller wrote: > Hi, > > Summary: > > Patch includes multiple minor code quality improvements and also fixes one > possible null pointer segfault on Mac. > After this patch, compilation on Mac OS X is error/warning free even with gcc > -Wall setting. > I'll submit more code quality patches later that focus more on > linux/win/java. > > Fixes: > > Code quality: > - First level parentheses around assignment used as while-loop truth value > - Some printf formats not a string literals and including no format arguments > > Invalid null pointer usage: > - Mac: IOMasterPort was called with (int)NULL which does not always resolve > to segfault safe value. Corrected to use MACH_PORT_NULL instead. > > Patch: > > The patch is against CVS head (@2009/09/09). > Attached patch file is in 'cvs diff -up' format. > > I'll commit this patch to the CVS later this week if there are no objections. > Feel free to comment. > These ifdefs can go. If you like I can remove them when you are done. #ifdef DEBUG_MW mexErrMsgTxt( msg ); #else They are just printf like debug messages for use in an environment in which I could not get directly to stderr/stdout. I don't think anyone uses them anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Sep 9 19:17:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:17:43 -0600 (MDT) Subject: [Rxtx] 2.2 Release plans In-Reply-To: <4AA7C707.5060802@attglobal.net> References: <4AA7C707.5060802@attglobal.net> Message-ID: On Wed, 9 Sep 2009, David Schmidt wrote: > I'm holding off releasing an update to my project (adtpro.sourceforge.net) to > support OSX Snow Leopard because I'd like to ship an "official" build of rxtx > 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for > toggling a port off). CVS is looking great on OSX - thanks to all who have > been hard at work on that. I wish there were just one more update - Pre3? > :-) > > My question... If I wanted to make a release in, say, a week... would it pay > to wait for rxtx, or should I plan to build and ship a local build of 2.2 out > of CVS myself? > Hi David, I would suggest planning on shipping a local build in a 1 week timeframe. We could put another prerelease up but there are still fixes coming in. -- Trent Jarvi tjarvi at qbang.org From ilkka at myller.com Wed Sep 9 23:07:34 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:07:34 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: <04A41559-598C-4B6E-821A-DA90CB6228E7@myller.com> Patch (im-20090909.patch) has been committed to the CVS. Trent: I'll include DEBUG_MW cleanup to my next patch. > > On Wed, 9 Sep 2009, Ilkka Myller wrote: > >> Hi, >> >> Summary: >> >> Patch includes multiple minor code quality improvements and also >> fixes one possible null pointer segfault on Mac. >> After this patch, compilation on Mac OS X is error/warning free >> even with gcc -Wall setting. >> I'll submit more code quality patches later that focus more on >> linux/win/java. >> >> Fixes: >> >> Code quality: >> - First level parentheses around assignment used as while-loop >> truth value >> - Some printf formats not a string literals and including no format >> arguments >> >> Invalid null pointer usage: >> - Mac: IOMasterPort was called with (int)NULL which does not always >> resolve to segfault safe value. Corrected to use MACH_PORT_NULL >> instead. >> >> Patch: >> >> The patch is against CVS head (@2009/09/09). >> Attached patch file is in 'cvs diff -up' format. >> >> I'll commit this patch to the CVS later this week if there are no >> objections. >> Feel free to comment. >> > > These ifdefs can go. If you like I can remove them when you are done. > > #ifdef DEBUG_MW > mexErrMsgTxt( msg ); > #else > > They are just printf like debug messages for use in an environment > in which I could not get directly to stderr/stdout. I don't think > anyone uses them anymore. > > -- > Trent Jarvi > tjarvi at qbang.org From ilkka at myller.com Wed Sep 9 23:35:13 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:35:13 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= Message-ID: Hi, Summary: Patch fixes compiling on Linux distributions/kernels that dont ship with linux/utsrelease.h header and therefore have no UTS_RELEASE defined. Usually this applies only to newer distributions and/or kernels - for example Ubuntu 9.04. Fixes: The UTS_RELEASE vs uname checking in initialization functions is now done only in debug build and only when UTS_RELEASE is actually defined. Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910.patch Type: application/octet-stream Size: 9542 bytes Desc: not available URL: From ilkka at myller.com Thu Sep 10 06:43:02 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 15:43:02 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= In-Reply-To: References: Message-ID: Patch has been committed to CVS. > Hi, > > Summary: > > Patch fixes compiling on Linux distributions/kernels that dont ship > with linux/utsrelease.h header and therefore have no UTS_RELEASE > defined. > Usually this applies only to newer distributions and/or kernels - > for example Ubuntu 9.04. > > Fixes: > > The UTS_RELEASE vs uname checking in initialization functions is now > done only in debug build and only when UTS_RELEASE is actually > defined. > > Patch: > > The patch is against CVS head (@2009/09/10). > Attached patch file is in 'cvs diff -up' format. > > > Thanks, > > -- > I > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Thu Sep 10 09:08:01 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 18:08:01 +0300 Subject: [Rxtx] [Patch] Remove unused MathWorks MATLAB DEBUG_MW ifdefs Message-ID: <6DB57DB1-A47E-4435-9CD6-212B671A2849@myller.com> Summary: Patch removes unused MathWorks MATLAB timing debug ifdefs (DEBUG_MW). This is a request from Trent. Fixes: - Removes DEBUG_MW definitions - Removes unused mex....() function definitions - Corrects DEBUG_TIMING to work properly without mexPrintf (with Mac OS X specific format string fixes included) - Removes unused/duplicate timeval struct and DEBUG_TIMING definitions from SerialImp.c and SerialImp.h - Corrects fprintf call in SerialImp.cpp Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910b.patch Type: application/octet-stream Size: 9841 bytes Desc: not available URL: From Kapil_Gupta at hcl.in Thu Sep 10 10:25:29 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 10 Sep 2009 21:55:29 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, I am getting some problem with RXTX on macintosh (reading some data from the device attached to the usb port through usb to serial mechanism). I used the RXTX 2.1.7 then I got PortInUseException but after using 2.2pre it worked fine. But it works only for the first time, it hangs in the second time while opening the port. Please find the attached code. This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Thu Sep 10 13:00:14 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 22:00:14 +0300 Subject: [Rxtx] [Patch] Implement return value checking to file I/O calls Message-ID: Summary: The return value of some functions should always be used. For example, it is dangerous to not check the return value of a write(), read(), open(), fscanf() calls. This patch fixes such occurences in RXTX code. For example: unchecked read() call could result in later - and often seemingly unrelated - segfault due to undefined read buffer contents. After this patch the Linux build process is error/warning free even with gcc -Wall -Werror. Fixes: - Implemented return value checking to file I/O calls in SerialImp.c:fhs_lock(), uucp_lock() and is_device_locked() functions. - Added error recovery for fuserImp.c fscanf() calls. Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910c.patch Type: application/octet-stream Size: 3370 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Thu Sep 10 13:08:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 22:08:05 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> Hi Kapil, I believe this issue has been fixed in CVS version, but still exists in 2.2pre2 available from RXTX wiki. For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html As you've seen from the recent patches announced on this list, we are working very hard to make a new 2.2pre(?) release available. Meanwhile, you can compile your own RXTX binaries from CVS source. On Mac it should be exceptionally easy with new Xcode 3.x project files. Thank you for your patience, -- I > > I am getting some problem with RXTX on macintosh (reading some data > from the device attached to the usb port through usb to serial > mechanism). I used the RXTX 2.1.7 then I got PortInUseException but > after using 2.2pre it worked fine. But it works only for the first > time, it hangs in the second time while opening the port. From ilkka at myller.com Fri Sep 11 04:07:22 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 13:07:22 +0300 Subject: [Rxtx] [Patch] Windows build improvements (MinGW32, MSVC and LCC) Message-ID: <81D06766-8D51-485A-B2A2-624C8EA690BA@myller.com> Summary: Fixes various compiler warnings with Windows builds. Removes unused code blocks from compilation. After this patch the Windows build process is error/warning free with MinGW32, MSVC and LCC compilers - even with -Wall enabled. Does not fix: Latest LCC compiler version still fails even after this patch due to compiler trap error. Trap error does not specify source code location - it fails outputting SerialImp.obj binary. Compiling SerialImp.c without binary output works. Could this be a bug in LCC? Tested with clean RXTX source, latest standard LCC installation and with both Windows Vista SP1 x86 and Windows XP SP3 x86. Patch: The patch is against CVS (@2009/09/11). Attached patch file is in 'cvs diff -up' format. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090911.patch Type: application/octet-stream Size: 6673 bytes Desc: not available URL: From Kapil_Gupta at hcl.in Fri Sep 11 08:21:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Fri, 11 Sep 2009 19:51:24 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Ilkka, I tried getting the source code from the CVS but we could not able to do so, the CVS was not responding. Then we downloaded the 2.2 pre2 code and made the changes that are described in http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html but the problem didn't change. First time the device responds well and the second time it hangs. Did you see the code that we have sent to you, so that you can suggest if we are doing something wrong in our code. Again attaching if you have deleted that. Please suggest (does the CVS code can help rather using the patch provided by you?). Thanks, Kapil -----Original Message----- From: Ilkka Myller [mailto:ilkka at myller.com] Sent: Friday, September 11, 2009 12:38 AM To: Kapil Gupta Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Hi Kapil, I believe this issue has been fixed in CVS version, but still exists in 2.2pre2 available from RXTX wiki. For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html As you've seen from the recent patches announced on this list, we are working very hard to make a new 2.2pre(?) release available. Meanwhile, you can compile your own RXTX binaries from CVS source. On Mac it should be exceptionally easy with new Xcode 3.x project files. Thank you for your patience, -- I > > I am getting some problem with RXTX on macintosh (reading some data > from the device attached to the usb port through usb to serial > mechanism). I used the RXTX 2.1.7 then I got PortInUseException but > after using 2.2pre it worked fine. But it works only for the first > time, it hangs in the second time while opening the port. DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Fri Sep 11 09:33:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 18:33:33 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Hi Kapil, For CVS: Instructions at the old rxtx website are incorrect. Trent updated them, but to a wrong server address "qgang.org" -- the correct server is "qbang.org". Please follow instructions from rxtx wiki: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code About testing your code: When I have time (maybe this weekend), I'll test your code using Mac OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. What USB serial port you are using with your Mac? Something with FTDI chip? or maybe Prolific? What adapter driver version you are using? Just asking, so I can test with the same configuration. Meanwhile I suggest you: - Make sure you have the latest USB Serial adapter drivers, so we can eliminate past issues with those. - Check that you are not having multiple copies of librxtxSerial.jnilib (possibly different versions) in your java library path (=trouble;) - Check for any USB Serial adaptors kernel extension error messages in system log after testing your software (use Console.app to browse logs) -- I Kapil Gupta kirjoitti 11.9.2009 kello 17.21: > Hi Ilkka, > > I tried getting the source code from the CVS but we could not able > to do so, the CVS was not responding. Then we downloaded the 2.2 > pre2 code and made the changes that are described in http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html > but the problem didn't change. First time the device responds well > and the second time it hangs. > > Did you see the code that we have sent to you, so that you can > suggest if we are doing something wrong in our code. Again attaching > if you have deleted that. Please suggest (does the CVS code can help > rather using the patch provided by you?). > > Thanks, > Kapil > > -----Original Message----- > From: Ilkka Myller [mailto:ilkka at myller.com] > Sent: Friday, September 11, 2009 12:38 AM > To: Kapil Gupta > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second > time port open > > Hi Kapil, > > I believe this issue has been fixed in CVS version, but still exists > in 2.2pre2 available from RXTX wiki. > > For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html > > As you've seen from the recent patches announced on this list, we are > working very hard to make a new 2.2pre(?) release available. > > Meanwhile, you can compile your own RXTX binaries from CVS source. On > Mac it should be exceptionally easy with new Xcode 3.x project files. > > > Thank you for your patience, > > > -- > I > > >> >> I am getting some problem with RXTX on macintosh (reading some data >> from the device attached to the usb port through usb to serial >> mechanism). I used the RXTX 2.1.7 then I got PortInUseException but >> after using 2.2pre it worked fine. But it works only for the first >> time, it hangs in the second time while opening the port. > > > DISCLAIMER: > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential > and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of this > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > ----------------------------------------------------------------------------------------------------------------------- > From ilkka at myller.com Fri Sep 11 11:51:13 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 20:51:13 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Message-ID: <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> Ok, I debugged your code on Mac using USB-RS232 adapter + loopback adapter. My findings: there are no issues with RXTX in your code -- there are issues with threading and synchronization. Primary issue: you essentially lock the JVM main thread to 100% CPU usage with infinite loop: while (!processCompleted) { ; } Now.. I'm going to give you a bad advice, mostly because you have bigger threading issues there.. but we must continue somehow: A quick remedy to previous is: while (!processCompleted) { Thread.yield(); } Thread yielding gives other threads atleast a chance to run (and to processCompleted boolean to actually update in main thread context). What happens next is that your main-thread is allowed to continue and proceeds to closeConnection() call it otherwise would never reach. After that, connection closes properly.. main() method continues to "System.out.println(result);" and proceeds to exit JVM.. .. except.. Secondary issue: Exit is one thing JVM cant do since you have left a Timer thread hanging without proper closing in getData() method. Cancel it (uncomment that line) - and your code completes main() to a clean JVM exit. So, my advice to you is to focus on fixing threading, timers and synchronization. Design those well and everything works. Multithreading, done well or not, will not usually confuse RXTX ... but your own code might not be so lucky. -- I > > When I have time (maybe this weekend), I'll test your code using Mac > OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. >> >> Did you see the code that we have sent to you, so that you can >> suggest if we are doing something wrong in our code. Again >> attaching if you have deleted that. Please suggest (does the CVS >> code can help rather using the patch provided by you?). -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 11 15:19:26 2009 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 11 Sep 2009 17:19:26 -0400 Subject: [Rxtx] Can't run my Netbeans/Java s/w on a MAC Message-ID: <4AAABEDE.7020508@howardz.com> An HTML attachment was scrubbed... URL: From ilkka at myller.com Fri Sep 11 15:41:10 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 12 Sep 2009 00:41:10 +0300 Subject: [Rxtx] Can't run my Netbeans/Java s/w on a MAC In-Reply-To: <4AAABEDE.7020508@howardz.com> References: <4AAABEDE.7020508@howardz.com> Message-ID: <35D4BD73-B8CC-4DEE-A846-8858C9C9EBC7@myller.com> Hi, The bug that causes the segfault (invalid memory access) has been fixed (in CVS): http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html Next prerelease is coming (soon I hope), but the the 2.2pre2 fails when reopening the serial port on Mac OS X. -- I > > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] Jar > version = RXTX-2.2pre1 > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] native > lib Version = RXTX-2.2pre2 > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] Invalid > memory access of location 0x12b5e3938 rip=0x12955012f > 9/6/09 3:46:00 PM ReportCrash[6164] Saved crash report for java > [6162] version 13.0.0 (13.0.0) to /Users/myles/Library/Logs/ > DiagnosticReports/java_2009-09-06-154600_myles-PowerBook-PP-108.crash -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Fri Sep 11 20:15:31 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 11 Sep 2009 20:15:31 -0600 (MDT) Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Message-ID: On Fri, 11 Sep 2009, Ilkka Myller wrote: > Hi Kapil, > > For CVS: > > Instructions at the old rxtx website are incorrect. Trent updated them, but > to a wrong server address "qgang.org" -- the correct server is "qbang.org". > Please follow instructions from rxtx wiki: > > http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code The old website has been corrected. -- Trent Jarvi tjarvi at qbang.org From dvd at newfoundmarket.com Sat Sep 12 11:49:48 2009 From: dvd at newfoundmarket.com (DVD) Date: Sat, 12 Sep 2009 13:49:48 -0400 Subject: [Rxtx] RXTX on linux hang Message-ID: <4AABDF3C.2040908@newfoundmarket.com> Hello: I just did a fresh install of RXTZ on both Ubuntu and centos, Java version 6, update 12 I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with the Usage example from your website Two way communcation with the serial port I used the computer's serial port /dev/ttyS0, with UART 16550A the program simply hang. The port was opened and both input/output streamed were opened but the writing/reading are not working. Any help would be appreciated. I tried this program on windows and it worked fine. Thanks From ilkka at myller.com Sat Sep 12 15:31:26 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sun, 13 Sep 2009 00:31:26 +0300 Subject: [Rxtx] RXTX on linux hang In-Reply-To: <4AABDF3C.2040908@newfoundmarket.com> References: <4AABDF3C.2040908@newfoundmarket.com> Message-ID: Hi, It's very hard to say what could be wrong without more details. Can you tell me more about your Linux setup: - Output of: uname -a - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your test code running) - Output of: cat /proc/tty/driver/serial - Are you you testing with root privileges - What kind of device you are communicating with (or just a loopback dongle)? - Does your device expect some specific flow control and/or specific state of DTR/DSR signals? - Have you tried configuring those flow controls and other RS232 signals in your test code? Did they work? - Do other simple terminal programs work (easiest to try: screen /dev/ ttyS0 )? - What is the CPU usage (use 'top' or some other process monitor your like) of your test software when it "hangs"? I can try to duplicate your issue on Ubuntu 9.04 (both x86 and x86_64), Centos 5 (x86) and Debian 5.0 (x86). I'd prefer to test with the same kind of system you have.. Thanks, -- I > > I just did a fresh install of RXTZ on both Ubuntu and centos, Java > version 6, update 12 > I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with > the Usage example from > your website > > Two way communcation with the serial port > > > I used the computer's serial port /dev/ttyS0, with UART 16550A > > the program simply hang. The port was opened and both input/output > streamed were opened > but the writing/reading are not working. > > Any help would be appreciated. I tried this program on windows and > it worked fine. From dvd at newfoundmarket.com Sat Sep 12 21:20:14 2009 From: dvd at newfoundmarket.com (DVD) Date: Sat, 12 Sep 2009 23:20:14 -0400 Subject: [Rxtx] RXTX on linux hang In-Reply-To: References: <4AABDF3C.2040908@newfoundmarket.com> Message-ID: <4AAC64EE.7050904@newfoundmarket.com> Thank you very much for the steps. It is pin out problem. Again, Thanks. Ilkka Myller wrote: > Hi, > > It's very hard to say what could be wrong without more details. > Can you tell me more about your Linux setup: > > - Output of: uname -a > - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your > test code running) > - Output of: cat /proc/tty/driver/serial > - Are you you testing with root privileges > - What kind of device you are communicating with (or just a loopback > dongle)? > - Does your device expect some specific flow control and/or specific > state of DTR/DSR signals? > - Have you tried configuring those flow controls and other RS232 > signals in your test code? Did they work? > - Do other simple terminal programs work (easiest to try: screen > /dev/ttyS0 )? > - What is the CPU usage (use 'top' or some other process monitor your > like) of your test software when it "hangs"? > > > I can try to duplicate your issue on Ubuntu 9.04 (both x86 and > x86_64), Centos 5 (x86) and Debian 5.0 (x86). > I'd prefer to test with the same kind of system you have.. > > > Thanks, > > -- > I > > >> >> I just did a fresh install of RXTZ on both Ubuntu and centos, Java >> version 6, update 12 >> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with >> the Usage example from >> your website >> >> Two way communcation with the serial port >> >> >> >> I used the computer's serial port /dev/ttyS0, with UART 16550A >> >> the program simply hang. The port was opened and both input/output >> streamed were opened >> but the writing/reading are not working. >> >> Any help would be appreciated. I tried this program on windows and >> it worked fine. > From tjarvi at qbang.org Sun Sep 13 12:06:33 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Sep 2009 12:06:33 -0600 (MDT) Subject: [Rxtx] RXTX on linux hang In-Reply-To: <4AAC64EE.7050904@newfoundmarket.com> References: <4AABDF3C.2040908@newfoundmarket.com> <4AAC64EE.7050904@newfoundmarket.com> Message-ID: Hi, Would it be possible to get a short paragraph from you describing the pinout problem and how you discovered it? We can add that to the wiki to help others get past the problem faster next time. On Sat, 12 Sep 2009, DVD wrote: > Thank you very much for the steps. It is pin out problem. > Again, Thanks. > > Ilkka Myller wrote: >> Hi, >> >> It's very hard to say what could be wrong without more details. >> Can you tell me more about your Linux setup: >> >> - Output of: uname -a >> - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your test >> code running) >> - Output of: cat /proc/tty/driver/serial >> - Are you you testing with root privileges >> - What kind of device you are communicating with (or just a loopback >> dongle)? >> - Does your device expect some specific flow control and/or specific state >> of DTR/DSR signals? >> - Have you tried configuring those flow controls and other RS232 signals in >> your test code? Did they work? >> - Do other simple terminal programs work (easiest to try: screen /dev/ttyS0 >> )? >> - What is the CPU usage (use 'top' or some other process monitor your like) >> of your test software when it "hangs"? >> >> >> I can try to duplicate your issue on Ubuntu 9.04 (both x86 and x86_64), >> Centos 5 (x86) and Debian 5.0 (x86). >> I'd prefer to test with the same kind of system you have.. >> >> >> Thanks, >> >> -- >> I >> >> >>> >>> I just did a fresh install of RXTZ on both Ubuntu and centos, Java version >>> 6, update 12 >>> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with the >>> Usage example from >>> your website >>> >>> Two way communcation with the serial port >>> >>> >>> I used the computer's serial port /dev/ttyS0, with UART 16550A >>> >>> the program simply hang. The port was opened and both input/output >>> streamed were opened >>> but the writing/reading are not working. >>> >>> Any help would be appreciated. I tried this program on windows and it >>> worked fine. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dvd at newfoundmarket.com Sun Sep 13 19:18:08 2009 From: dvd at newfoundmarket.com (DVD) Date: Sun, 13 Sep 2009 21:18:08 -0400 Subject: [Rxtx] RXTX on linux hang In-Reply-To: References: <4AABDF3C.2040908@newfoundmarket.com> <4AAC64EE.7050904@newfoundmarket.com> Message-ID: <4AAD99D0.3030206@newfoundmarket.com> Hello, It was a human mistake during wiring and was discovered after staring at it for a while :-). Nothing technical worth mentioning. Thanks Trent Jarvi wrote: > > Hi, > > Would it be possible to get a short paragraph from you describing the > pinout problem and how you discovered it? We can add that to the wiki > to help others get past the problem faster next time. > > On Sat, 12 Sep 2009, DVD wrote: > >> Thank you very much for the steps. It is pin out problem. >> Again, Thanks. >> >> Ilkka Myller wrote: >>> Hi, >>> >>> It's very hard to say what could be wrong without more details. >>> Can you tell me more about your Linux setup: >>> >>> - Output of: uname -a >>> - Output of: stty -a -F /dev/ttyS0 (if possible: with and without >>> your test code running) >>> - Output of: cat /proc/tty/driver/serial >>> - Are you you testing with root privileges >>> - What kind of device you are communicating with (or just a loopback >>> dongle)? >>> - Does your device expect some specific flow control and/or specific >>> state of DTR/DSR signals? >>> - Have you tried configuring those flow controls and other RS232 >>> signals in your test code? Did they work? >>> - Do other simple terminal programs work (easiest to try: screen >>> /dev/ttyS0 )? >>> - What is the CPU usage (use 'top' or some other process monitor >>> your like) of your test software when it "hangs"? >>> >>> >>> I can try to duplicate your issue on Ubuntu 9.04 (both x86 and >>> x86_64), Centos 5 (x86) and Debian 5.0 (x86). >>> I'd prefer to test with the same kind of system you have.. >>> >>> >>> Thanks, >>> >>> -- >>> I >>> >>> >>>> >>>> I just did a fresh install of RXTZ on both Ubuntu and centos, Java >>>> version 6, update 12 >>>> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with >>>> the Usage example from >>>> your website >>>> >>>> Two way communcation with the serial port >>>> >>>> >>>> I used the computer's serial port /dev/ttyS0, with UART 16550A >>>> >>>> the program simply hang. The port was opened and both input/output >>>> streamed were opened >>>> but the writing/reading are not working. >>>> >>>> Any help would be appreciated. I tried this program on windows and >>>> it worked fine. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From Kapil_Gupta at hcl.in Mon Sep 14 08:37:23 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Mon, 14 Sep 2009 20:07:23 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B30A4F25D@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Ilkka, We have done that also, but no success. I am attaching the code, please check the updated code also. We are not using any FTDI/Prolific chip set. We are using TI chip set. We are having only one copy of JNI lib. No Error in console for kernel driver. Warm Regards, Kapil From: Ilkka Myller [mailto:ilkka at myller.com] Sent: Friday, September 11, 2009 11:21 PM To: Kapil Gupta Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Ok, I debugged your code on Mac using USB-RS232 adapter + loopback adapter. My findings: there are no issues with RXTX in your code -- there are issues with threading and synchronization. Primary issue: you essentially lock the JVM main thread to 100% CPU usage with infinite loop: while (!processCompleted) { ; } Now.. I'm going to give you a bad advice, mostly because you have bigger threading issues there.. but we must continue somehow: A quick remedy to previous is: while (!processCompleted) { Thread.yield(); } Thread yielding gives other threads atleast a chance to run (and to processCompleted boolean to actually update in main thread context). What happens next is that your main-thread is allowed to continue and proceeds to closeConnection() call it otherwise would never reach. After that, connection closes properly.. main() method continues to "System.out.println(result);" and proceeds to exit JVM.. .. except.. Secondary issue: Exit is one thing JVM cant do since you have left a Timer thread hanging without proper closing in getData() method. Cancel it (uncomment that line) - and your code completes main() to a clean JVM exit. So, my advice to you is to focus on fixing threading, timers and synchronization. Design those well and everything works. Multithreading, done well or not, will not usually confuse RXTX ... but your own code might not be so lucky. -- I When I have time (maybe this weekend), I'll test your code using Mac OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. Did you see the code that we have sent to you, so that you can suggest if we are doing something wrong in our code. Again attaching if you have deleted that. Please suggest (does the CVS code can help rather using the patch provided by you?). DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10005 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Mon Sep 14 17:03:55 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 15 Sep 2009 02:03:55 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B30A4F25D@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B30A4F25D@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <989B2FAA-5E5A-4F47-AF23-04CE1A6A20F7@myller.com> Kapil, You did not fix the primary issue. Your while() loop still blocks the main thread and the code is not working for the same reasons I stated before. .. but .. I created a demonstration code, which does not try to duplicate the behaviour of your code, but instead demonstrates few concepts: 1. Safe opening of the serial port with full error checking 2. Proper handling of text encoding using Reader/Writer. If your protocol handles plaintext, I recommend you use encoding capable streams. 3. Asynchronous multi-threaded receiving and transmitting (separate thread for each, with their own packet (=string, in this case) queues) 4. Handling serial port data-available events without blocking the event handler (=event only signals async. receiver) 5. Controlling access to serial port in multithreaded app using ReentrantLock (still allows embedded transmit->receive, as demonstrated) 6. Signaling thread from other thread with wait() -> notify() (demonstrated in serial event handling) The code does one simple thing: sends a US-ASCII encoded string to serial port with CR+LF and expects the same line to be received back. I used simple loopback adapter hardware to test this. Normally, doing just this simple task does not require such heavy multi-threading async. receiver/transmitter structures, but I created them to demonstrate various multi-threading concepts, and how they can be used with RXTX. The code is not perfect, it's still a quick hack to demonstrate few things. For example, it lacks proper error handling and propagation in async. receiver/transmitter. However, this code is "profiler clean". It's threads are mostly idle waiting other threads or actual events from RXTX. No thread is blocked in high CPU-% loops etc. when receiving or sending. This also scales nicely to run on multiple CPU's with modern JVM's. When implementing commercial protocol handlers this is how things should always be. Doing "while(someBoolean) {}" is generally not the correct method to sync things. -- I > Hi Ilkka, > > We have done that also, but no success. I am attaching the code, > please check the updated code also. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 11656 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail4ng at gmail.com Tue Sep 15 03:02:48 2009 From: mail4ng at gmail.com (Daniel Weinand) Date: Tue, 15 Sep 2009 11:02:48 +0200 Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby Message-ID: <4AAF5838.7080707@gmail.com> Hello, i'm using RXTX with a USB to Serial Adapter on Linux and Windows machines. Everything works great. but now i have a problem on a Vista machine with standby mode. after the machine wakes up i'll get an infinite error loop: Error 0x5 at ..\src\termios.c(2712): Access Denied Error 0x5 at ..\src\termios.c(517): Access Denied ... and so on. My Application runs as a windows service and so it tries to enumerate and connect to the port directly after it wakes up. but the Port is blocked until i restart the whole machine and everything starts from 0. i'm using rxtx 2.2pre2 is this a known problem and how to solve this? From stefan.frings at vodafone.com Tue Sep 15 09:08:04 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Tue, 15 Sep 2009 17:08:04 +0200 Subject: [Rxtx] Reloading C library after USB error Message-ID: Hello, I wrote a web application that uses rxtxcomm to communicate to USB devices through virtual serial ports (e.g. /dev/ttyUSB0) on Linux. When I unplug a device while the port is open and then plug it back, I cannot access it anymore. I need to kill -9 Tomcat and then restart it. I think that I need to re-load the C library. Another problem occurs when I plug in an USB device after my web application has started. In this case, the new device cannot be accessed through rxtxcomm. Again, I assume that I need to relaod the C library. I am not able to shut-down my web application after these two errors occur. Tomcat reports, that the shut-down failed. How can I reload the C library without hardly killing my running Tomcat? -------------- next part -------------- An HTML attachment was scrubbed... URL: From petter.real at gmail.com Tue Sep 15 14:32:29 2009 From: petter.real at gmail.com (Petter Rafael Villa Real) Date: Tue, 15 Sep 2009 17:32:29 -0300 Subject: [Rxtx] RXTX on Ubuntu 9.04 with lock in /var/lock/LCK..ttyS0. Message-ID: Hi, I always used the RXTX to read/write the serial successfully on Windows. But now I need to use Linux Ubuntu 9.04, I changed to COM1, with on Windows, to /dev/ttyS0, the reading starts on the terminal but the RXTX will warn that you must release the lock of the serial. In the RXTX documentation is indicated add uucd User groups and / or lock to resolve this problem, but in Ubuntu do not have this group. Does anyone have experience with Ubuntu to help me? P.S.: sorry for my bad english. Thank you. -- -- --------------------------------------------------------------------- Petter R. Villa Real Silva -- Desenvolvedor Web Viamais Desenvolvimento Web Powered by Java/Oracle PHP/MySQL Web Alocation e Hosting - PHP/JSP --------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at attglobal.net Tue Sep 15 19:36:38 2009 From: david at attglobal.net (David Schmidt) Date: Tue, 15 Sep 2009 21:36:38 -0400 Subject: [Rxtx] 2.2 Release plans In-Reply-To: References: <4AA7C707.5060802@attglobal.net> Message-ID: <4AB04126.5070002@attglobal.net> Trent Jarvi wrote: > On Wed, 9 Sep 2009, David Schmidt wrote: > >> I'm holding off releasing an update to my project >> (adtpro.sourceforge.net) to support OSX Snow Leopard because I'd like >> to ship an "official" build of rxtx 2.2. (I wouldn't mind shipping >> 2.2Pre2, but it lacks a critical fix for toggling a port off). CVS is >> looking great on OSX - thanks to all who have been hard at work on >> that. I wish there were just one more update - Pre3? :-) >> >> My question... If I wanted to make a release in, say, a week... would >> it pay to wait for rxtx, or should I plan to build and ship a local >> build of 2.2 out of CVS myself? >> > > Hi David, > > I would suggest planning on shipping a local build in a 1 week > timeframe. We could put another prerelease up but there are still fixes > coming in. Thanks for the encouragement, guys. I'm having a little less luck now - building for OSX on an Intel box runs on a PPC box, but not on Intel... weird. I guess I'll wait a bit more. :-) - David From david at attglobal.net Tue Sep 15 19:51:28 2009 From: david at attglobal.net (David Schmidt) Date: Tue, 15 Sep 2009 21:51:28 -0400 Subject: [Rxtx] FTDI chipset speed - much slower? Message-ID: <4AB044A0.10509@attglobal.net> I am finding that my app is behaving really slowly when I'm connecting with a FTDI chipset equipped USB-serial adapter. I'm finding my app to be "fast" when I use native UART ports, Prolific or Keyspan USB adapters. But my FTDI adapters are remarkably, astonishingly slower when sending data (in my case, this means moving data from the DE-9 to the USB end) than any other method. I mean it is maybe 1/5 the "normal" speed I see from every other method. CPU remains calm on the USB (i.e. Mac or PC) end of the adapter. It's just really slow. Data moving in the other direction seems to run at full speed. I'm suspecting I'm doing something wrong along the way that is reacting badly with this chipset. My initial, lazy question, before exposing my code to the harsh light of day: is there anything obvious I might be doing wrong to this chipset to make it run so slowly? Has anyone else run into the same problem? - David From tjarvi at qbang.org Tue Sep 15 20:03:51 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 15 Sep 2009 20:03:51 -0600 (MDT) Subject: [Rxtx] FTDI chipset speed - much slower? In-Reply-To: <4AB044A0.10509@attglobal.net> References: <4AB044A0.10509@attglobal.net> Message-ID: On Tue, 15 Sep 2009, David Schmidt wrote: > I am finding that my app is behaving really slowly when I'm connecting > with a FTDI chipset equipped USB-serial adapter. I'm finding my app to be > "fast" when I use native UART ports, Prolific or Keyspan USB adapters. > But my FTDI adapters are remarkably, astonishingly slower when sending > data (in my case, this means moving data from the DE-9 to the USB end) > than any other method. I mean it is maybe 1/5 the "normal" speed I see > from every other method. CPU remains calm on the USB (i.e. Mac or PC) end > of the adapter. It's just really slow. Data moving in the other > direction seems to run at full speed. > > I'm suspecting I'm doing something wrong along the way that is reacting > badly with this chipset. My initial, lazy question, before exposing my > code to the harsh light of day: is there anything obvious I might be doing > wrong to this chipset to make it run so slowly? Has anyone else run into > the same problem? > Given that rxtx does not treat usb special, it may be something to do with the nature of USB serial dongles. One suspicion I've had is that the event loop is competing for bandwidth by trying to check the UART status which is on the other side of the USB line. 1/5th is fairly significant. This is just writing/reading? How large are the transfers? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 15 20:07:12 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 15 Sep 2009 20:07:12 -0600 (MDT) Subject: [Rxtx] Reloading C library after USB error In-Reply-To: References: Message-ID: On Tue, 15 Sep 2009, Frings, Stefan, VF-DE wrote: > Hello, > ? > I wrote a web application that uses rxtxcomm to communicate to USB > devices through virtual serial ports (e.g. /dev/ttyUSB0) on Linux. > ? > When I unplug a device while the port is open and then plug it back, I > cannot access it anymore. I need to kill -9 Tomcat and then restart it. I > think that?I need to re-load the C library. > ? > Another problem occurs when I plug in an USB device after my web > application has started. In this case, the new device cannot be accessed > through rxtxcomm. Again, I assume that I need to relaod the C library. > ? > I am not able to shut-down my web application after these two errors > occur.? Tomcat reports, that the shut-down failed. > ? > How can I reload the C library without hardly killing my running Tomcat? > > I don't think the native library needs to shut down but the code does not expect the file descriptor to go invalid. Duct taping the USB dongle isnt always an option but thats how rxtx is currently coded. read/write and the event loop could all fail at any time and need to shut down the port. This code is not in place. We don't get USB events through the API so it has to be done by checking errors. The library also needs the ability to rescan the available ports. When it was written, you had to shut down the computer to remove a serial port so rescanning wasnt a concern. If those two fixes are made, you will be able to exit tomcat gracefully. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 15 20:08:54 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 15 Sep 2009 20:08:54 -0600 (MDT) Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby In-Reply-To: <4AAF5838.7080707@gmail.com> References: <4AAF5838.7080707@gmail.com> Message-ID: On Tue, 15 Sep 2009, Daniel Weinand wrote: > Hello, > > i'm using RXTX with a USB to Serial Adapter on Linux and Windows machines. > Everything works great. > but now i have a problem on a Vista machine with standby mode. after the > machine wakes up i'll get an infinite error loop: > > > Error 0x5 at ..\src\termios.c(2712): Access Denied > Error 0x5 at ..\src\termios.c(517): Access Denied > ... > > and so on. > > My Application runs as a windows service and so it tries to enumerate and > connect to the port directly > after it wakes up. but the Port is blocked until i restart the whole > machine and everything starts from 0. > > i'm using rxtx 2.2pre2 > > is this a known problem and how to solve this? It is a known problem. The kernel driver isnt restoring the fd. See the previous post for what is required prior to being able to handle it in your code. -- Trent Jarvi tjarvi at qbang.org From nsp25 at cornell.edu Tue Sep 15 20:50:11 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 15 Sep 2009 22:50:11 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> Message-ID: Thank you very much Ikka and Mike. Sorry I didn't get back sooner, but your emails got buried in my inbox, and I didn't see them until yesterday, or get to try it out until today. The following body of the connect method worked (same serial cable): SerialPort port = (SerialPort) CommPortIdentifier.getPortIdentifier("COM1").open("", 1000); port.setSerialPortParams(baud, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); // Never tried this before, it was just one or the other port.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT); port.setRTS(true); // Seems to work when flow control is set right port.setDTR(false); // Just in case port.disableReceiveTimeout(); However, I noticed what could be a bug in RXTX for Windows XP. While running PortMon, I discovered what could be problems in the (attached) log file, namely INVALID_PARAMETER return codes for IOCTL_SERIAL_CLR_RTS happens, I believe) and twice for IOCTL_SERIAL_SET_RTS. The log is nearly identical each time I connect, with the same failures. What's the easiest way I can run RXTX in debug mode? I have visual studio 2008, if that helps. If anyone wants to help me track this (new?) bug down, I can provide whatever computer information you ask for. -Nate On Wed, Sep 9, 2009 at 8:57 AM, Michael Tandy wrote: > OK, I just ran a test with my copy of RxTx and the following program: > > import gnu.io.*; > public class SerialTest { > public static void main(String[] args) { > > try { > CommPortIdentifier portid = > CommPortIdentifier.getPortIdentifier("COM9"); > SerialPort serialPort = (SerialPort)portid.open("Serial > port DTR/RTS test", 1000); > serialPort.setSerialPortParams(4800, > SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > serialPort.disableReceiveTimeout(); > for (int i=0 ; i<60 ; i++) { > serialPort.setDTR(true); > serialPort.setRTS(true); > Thread.sleep(1000); > serialPort.setDTR(false); > serialPort.setRTS(false); > Thread.sleep(1000); > } > } catch (Exception e) { > e.printStackTrace(); > System.exit(1); > } > System.exit(0); > } > } > > I'm using a USB-serial converter (Prolific PL-2303) and I used a > multimeter to check that my DTR and RTS pins were both toggling, and > they were - between +7 and -6.4 volts. > > In other words, on the computer I'm using at the moment, with the > version of RxTx I'm using at the moment, setDTR and setRTS both seem > to work fine. I don't know if it's worth it for you to perform the > same test. > > I gather there are several different configurations for hardware flow > control, (DTR/DSR handshaking as well as RTS/CTS handshaking, > handshaking for half-duplex operation, and similar) so the cable that > worked for me might still be worth a try. > > > 2009/9/9 Michael Tandy : > > I had a similar problem a while ago - hardware that would work with > > Hyperterminal but not with Rxtx. > > > > I don't know if this is a bug in RxTx or not - I tried to find where > > in the RxTx source code those functions are actually implemented - I > > got as far as the ioctl function in termios.c, where the TIOCMSET case > > sets the MSR byte in the termios struct, but I can't figure out where > > that gets written to the dcb struct's fDtrControl dword. It could be a > > bug, or it could just be me missing something. > > > > In any case, at the time I had this problem I wasn't equipped to debug > > RxTx so instead I created a special cable to satisfy the hardware's > > flow control while leaving the data connection straight through. > > Here's how I connected it: > > > > At the female end of the cable (i.e. the hardware I was connecting to) > > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > > I connected the ground and data pins straight through - that is, pin 5 > > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > > 3 female end to pin 3 male end. > > > > Anyway, using that cable bypassed the hardware's flow control, and got > > RxTx working just as well as HyperTerminal - although I slowed down my > > communication to make sure I didn't encounter a situation where the > > flow control would have come into effect, as I had bypassed it! > > > > Hope that helps. > > > > > > 2009/9/9 Nathaniel S. Parsons : > >> I added a call to setRTS() but nothing changed in Serial Port Monitor, > no > >> matter what the argument was. Is this a bug, or did I call the wrong > >> function? > >> > >> I tried to find the c code behind this function, and I think I found it > in > >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look > wrong > >> to me. Am I looking at the right function or is the problem somewhere > else? > >> > >> -Nate > >> > >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > > >> wrote: > >>> > >>> Thanks for the response. I'll try to get to the electronics store > tomorrow > >>> to get more serial cables, even if it isn't the problem. > >>> > >>> I am using a different serial cable than I was in the spring. It's > >>> actually a Male/Female cable with a female-female adapter since the old > >>> cables aren't around anymore. The hardware's manual says nothing except > to > >>> use a "Straight cable" but I figured that if it worked in > HyperTerminal, it > >>> should work in RXTX, right? > >>> > >>> Anyways, I've also noticed some things that are different between > >>> HyperTerminal, RXTX, and a separate program I found that communicates > with > >>> the device (but doesn't do what I want, which is why I'm rolling my own > >>> program) > >>> > >>> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS > and > >>> DTR indicators are green > >>> Other program - not sure what settings it thinks it's using, but only > >>> SPM's RTS indicator is green > >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR > >>> indicators are on. > >>> > >>> From Serial Port Monitor's help files (paraphrased): the indicators > >>> display the state of the serial control lines > >>> > >>> RTS - Request To Send > >>> CTS - Clear To Send > >>> DTR - Data Terminal Ready > >>> > >>> Could this be related to the problem? > >>> > >>> -Nate > >>> > >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy > > >>> wrote: > >>>> > >>>> OK, so: > >>>> > >>>> 1. It worked in spring but has stopped doing so and > >>>> 2. The data all arrives at once when you start hyperterminal. > >>>> > >>>> Is it possible you're using a different serial cable to connect to the > >>>> device, compared to the one you were using in spring? > >>>> > >>>> If so, the issue might be hardware flow control - that is, your device > >>>> might be buffering data because it can't transmit it until your > >>>> computer sets 'DTR' or 'RTS' or something like that. > >>>> > >>>> One way of bypassing hardware flow control is by using cables which > >>>> cross over certain wires so that the right signals are always being > >>>> sent; it's possible your old cable had these connections but your > >>>> current cable doesn't have them. If you can find the old cable, you > >>>> could put it back in and see if that fixes things? > >>>> > >>>> > >>>> 2009/9/8 Nathaniel S. Parsons : > >>>> > (Sorry if this is a double post, but I sent my original message > without > >>>> > subscribing, and since this is an urgent problem, I thought I'd > resend > >>>> > after > >>>> > subscribing to bypass the moderator limbo zone) > >>>> > > >>>> > Hi all, > >>>> > > >>>> > I've asked my question on StackOverflow already, so rather than > >>>> > copy-paste > >>>> > the question here, I'd like to redirect you there. > >>>> > > >>>> > Short version, I am no longer able to receive anything over RS-232 > with > >>>> > RXTX, but other programs work fine. I'm definitely sending things, > >>>> > because > >>>> > when I connect with a different program, all the responses to the > >>>> > commands I > >>>> > sent via RXTX arrive all at once. > >>>> > > >>>> > Everything was fine in the spring, so what could have happened? > Windows > >>>> > update? > >>>> > > >>>> > -Nate > >>>> > > >>>> > _______________________________________________ > >>>> > Rxtx mailing list > >>>> > Rxtx at qbang.org > >>>> > http://mailman.qbang.org/mailman/listinfo/rxtx > >>>> > > >>>> > > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at qbang.org > >>>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: connection_log.csv Type: application/octet-stream Size: 9725 bytes Desc: not available URL: From stefan.frings at vodafone.com Wed Sep 16 00:06:52 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Wed, 16 Sep 2009 08:06:52 +0200 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time Message-ID: Hello Daniel Weinand, your proble is surely related to my issue. Im not familiar with Mac OS, but I know that Linux and also Windows normally disconnect all USB devices during standby mode and reconnect them after power-on. RxTx seems to have a problem when a device disappears or appears while the C library is loaded. I think the C library should be changed to re-check the list of available ports whenever the Java application attempts to enumerate or open a port. And when a port disappears while it is open, the library should close it and throw an AlreadyClosedException. I think the Java application should be able to recover itself from temporarily lost devices, and it should also be able to open devices that have been plugged in AFTER the library was loaded. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.frings at vodafone.com Wed Sep 16 00:09:34 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Wed, 16 Sep 2009 08:09:34 +0200 Subject: [Rxtx] Reloading C library after USB error In-Reply-To: References: Message-ID: Hello Trent, Yes, I think the same. The library was obviously not written for USB devices. Is anybody aware of an alternative that works fine with USB / Hotpluggable devices? From stefan.frings at vodafone.com Wed Sep 16 00:12:58 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Wed, 16 Sep 2009 08:12:58 +0200 Subject: [Rxtx] RXTX on Ubuntu 9.04 with lock in /var/lock/LCK..ttyS0 Message-ID: Hello Petter, the serial ports are normally only writeable by root and by users that are in the dialout group. For your case, a solution might be, to add yourself to the dialout group in /etc/group. On my machines, RxTx wporks fine. I am using Ubuntu 8.10 and 9.04 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.frings at vodafone.com Wed Sep 16 00:17:27 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Wed, 16 Sep 2009 08:17:27 +0200 Subject: [Rxtx] FTDI chipset speed - much slower? Message-ID: Hello David, Im not 100% sure, but I highly assume that the delays are produces by the USB communication. USB transfers data in packets and there are large buffers of several hundreds characters, similar to ethernet. There is no real time communication. So when your software thinks that it has sent a character, this was not the case. It was only put into a buffer and will appears at the end of your USB2Serial cable after some time - I assume somewhat around 0,3ms. I noticed the same behavious with different USB2Serial adapters on Linux with plain C programs (not anything around Java and RxTx). -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 16 01:06:41 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 16 Sep 2009 10:06:41 +0300 Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby In-Reply-To: References: <4AAF5838.7080707@gmail.com> Message-ID: <0EB22ACB-0676-44DE-BBD3-A9D38CFD2E88@myller.com> Windows is not my primary platform, but I agree with Trent. I tested this too and noticed that ClearCommError() does not fail because RXTX loses fd (why would it), but because fd seems to no longer exist, or is reused, on kernel side. Resulting in access denied (5) error. Definitely something RXTX has no control of. Also the USB device re-registers itself, causing all it's previous file handles invalidated. After few seconds after waking from sleep, new ones can be created with CreateFile calls - as expected. FTDI chips can be reprogrammed not to do this reconnection cycle on USB sleep (with mprog 3.5 software). I dont know how well Windows follows that setting. Also Windows allows disabling USB power saving on specific USB devices. After those settings, it entirely up to the USB driver to do the right thing. .. which I'm not entirely sure it will - even if it's technically possible to retain fd's over sleep the driver might still be hardwired to reconnect the device on power save events. -- Basicly all these issues are about the fact that someone/something rips off the UART hardware RXTX is controlling. The serial comms features on most operating systems are not equipped to handle this since UART is expected to be integral part of the system. Well, USB has certainly changed that. Now not only the serial device can be unplugged (which is handled properly by protocols etc.) but the actual interface hardware too. Like ripping off the engine from your car while driving. For those reasons this issue is very hard for RXTX or any other serial comms library to handle. We could detect errors from kernel that indicate the UART has vanished and proceed to do automatic reopening of the serial port after some delay at the native lib. But: this has multiple issues, which probably will break user protocols and software. One of those is the fact that reopening the port could toggle its CTS/RTS/DTR/DSR signals causing unexpected trouble on user side. Other one is that we might end up in infinite loop of comm error <-> automatic reopening without notifying rxtx java side. Not elegant. Not proper. -- I'm proposing a following solution: We could implement a method to detect lost UART in event loop at native lib side and introduce a new Java side SerialPortEvent type UART_DISCONNECT. The native lib would send that event in case of error and proceed to automatically close the serial port and clear the invalid handles etc. (reset to fault free state). That would allow user code to gracefully handle these situations, by doing whatever is necessary to restore communications with their protocols etc. Usually that includes opening the serial port and doing some initializations. Those who choose to ignore that event, or not implement any handling for it, can continue to use RXTX as any other serial comms lib. But their software would still tumble and fall on UART disconnects - mostly caused by USB->UART bridges. Atleast, we'd have a method for implementing proper recovery if RXTX user chooses to do so. Beats duct tape+USB dongle combo anytime;) Feedback welcome :) -- I > > > On Tue, 15 Sep 2009, Daniel Weinand wrote: >> >> Error 0x5 at ..\src\termios.c(2712): Access Denied >> Error 0x5 at ..\src\termios.c(517): Access Denied >> ... > > It is a known problem. The kernel driver isnt restoring the fd. > See the previous post for what is required prior to being able to > handle it in your code. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 16 01:18:14 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 16 Sep 2009 10:18:14 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time In-Reply-To: References: Message-ID: I'm referring to my previous post and to my proposal for handling these situations (detection + java side event): In addition to UART_DISCONNECT event I proposed, your suggestion about AlreadyClosedException is great. We'd still have to handle existing "opened port objects" in Java side even after sending the UART_DISCONNECT event. Making them throw AlreadyClosedException would do that elegantly. -- I Frings, Stefan, VF-DE kirjoitti 16.9.2009 kello 9.06: > > And when a port disappears while it is open, the library should > close it and throw an AlreadyClosedException. > > I think the Java application should be able to recover itself from > temporarily lost devices, and it should also be able to open devices > that have been plugged in AFTER the library was loaded. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at attglobal.net Wed Sep 16 03:47:59 2009 From: david at attglobal.net (David Schmidt) Date: Wed, 16 Sep 2009 05:47:59 -0400 Subject: [Rxtx] FTDI chipset speed - much slower? In-Reply-To: References: <4AB044A0.10509@attglobal.net> Message-ID: <4AB0B44F.9060201@attglobal.net> Trent Jarvi wrote: > On Tue, 15 Sep 2009, David Schmidt wrote: >> I'm suspecting I'm doing something wrong along the way that is >> reacting badly with this chipset. My initial, lazy question, before >> exposing my code to the harsh light of day: is there anything obvious >> I might be doing wrong to this chipset to make it run so slowly? Has >> anyone else run into the same problem? > > Given that rxtx does not treat usb special, it may be something to do > with the nature of USB serial dongles. One suspicion I've had is that > the event loop is competing for bandwidth by trying to check the UART > status which is on the other side of the USB line. > > 1/5th is fairly significant. This is just writing/reading? How large > are the transfers? The protocol is a little dance that happens with tiny packets, rapidly sending/receiving (http://adtpro.sourceforge.net/protocol.html#Get). Host sends: 2 bytes: current block number (LSB, MSB) 1 byte: half-block number (2 = bytes 0-255, 1 = bytes 256-511) up to 256 bytes: Half-block, RLE encoded two bytes: CRC (lo) CRC (hi) Apple sends: One byte: acknowledgement Two bytes: current block number (LSB, MSB) One byte: half-block number (2 = bytes 0-255, 1 = bytes 256-511) (repeat) As others have mentioned, it may be the chipset waiting until that 16-byte on-chip buffer fills up, as the acknowledgment packet is really small. And, the payload packet size can be really small if all bytes are the same - RLE encoding would pack an "empty" block into just a few bytes too. - David From ozgurovic at hotmail.com Wed Sep 16 05:09:37 2009 From: ozgurovic at hotmail.com (Ozgur Erkent) Date: Wed, 16 Sep 2009 14:09:37 +0300 Subject: [Rxtx] FTDI chipset speed - much slower? In-Reply-To: <4AB0B44F.9060201@attglobal.net> References: <4AB044A0.10509@attglobal.net> <4AB0B44F.9060201@attglobal.net> Message-ID: Has anybody tried to experiment the latency time of FTDI USB2Serial? (its latency wrt serial port) after preferably sending command from the computer, probably by keeping track of time after command is sent, its echo back time. In different languages would be good to compare them. ?zg?r Erkent > Date: Wed, 16 Sep 2009 05:47:59 -0400 > From: david at attglobal.net > To: rxtx at qbang.org > Subject: Re: [Rxtx] FTDI chipset speed - much slower? > > Trent Jarvi wrote: > > On Tue, 15 Sep 2009, David Schmidt wrote: > >> I'm suspecting I'm doing something wrong along the way that is > >> reacting badly with this chipset. My initial, lazy question, before > >> exposing my code to the harsh light of day: is there anything obvious > >> I might be doing wrong to this chipset to make it run so slowly? Has > >> anyone else run into the same problem? > > > > Given that rxtx does not treat usb special, it may be something to do > > with the nature of USB serial dongles. One suspicion I've had is that > > the event loop is competing for bandwidth by trying to check the UART > > status which is on the other side of the USB line. > > > > 1/5th is fairly significant. This is just writing/reading? How large > > are the transfers? > > The protocol is a little dance that happens with tiny packets, rapidly > sending/receiving (http://adtpro.sourceforge.net/protocol.html#Get). > > Host sends: > 2 bytes: current block number (LSB, MSB) > 1 byte: half-block number (2 = bytes 0-255, 1 = bytes 256-511) > up to 256 bytes: Half-block, RLE encoded > two bytes: > CRC (lo) > CRC (hi) > > Apple sends: > One byte: acknowledgement > Two bytes: current block number (LSB, MSB) > One byte: half-block number (2 = bytes 0-255, 1 = bytes 256-511) > > (repeat) > > As others have mentioned, it may be the chipset waiting until that > 16-byte on-chip buffer fills up, as the acknowledgment packet is really > small. And, the payload packet size can be really small if all bytes > are the same - RLE encoding would pack an "empty" block into just a few > bytes too. > > - David > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ More than messages?check out the rest of the Windows Live?. http://www.microsoft.com/windows/windowslive/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Wed Sep 16 05:15:23 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Wed, 16 Sep 2009 07:15:23 -0400 (EDT) Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby In-Reply-To: <0EB22ACB-0676-44DE-BBD3-A9D38CFD2E88@myller.com> Message-ID: <11479259.481253099719746.JavaMail.gjohnson@pippin.local> This is a big problem for us, and one we have resorted to the duct tape solution for as we can't find anything better :( The notion of an additional event coming up from the native code sounds very promising! Cheers, greg -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com ----- Original Message ----- From: "Ilkka Myller" To: "Trent Jarvi" , "Daniel Weinand" , "Stefan Frings, VF-DE" Cc: "rxtx at qbang.org" Sent: Wednesday, September 16, 2009 3:06:41 AM GMT -05:00 US/Canada Eastern Subject: Re: [Rxtx] Error 0x5 in termios.c after wake-up from standby Windows is not my primary platform, but I agree with Trent. I tested this too and noticed that ClearCommError() does not fail because RXTX loses fd (why would it), but because fd seems to no longer exist, or is reused, on kernel side. Resulting in access denied(5) error. Definitely something RXTX has no control of. Also the USB device re-registers itself, causing all it's previous file handles invalidated. After few seconds after waking from sleep, new ones can be created with CreateFile calls - as expected. FTDI chips can be reprogrammed not to do this reconnection cycle on USB sleep (with mprog 3.5 software). I dont know how well Windows follows that setting. Also Windows allows disabling USB power saving on specific USB devices. After those settings, it entirely up to the USB driver to do the right thing. .. which I'm not entirely sure it will - even if it's technically possible to retain fd's over sleep the driver might still be hardwired to reconnect the device on power save events. -- Basicly all these issues are about the fact that someone/something rips off the UART hardware RXTX is controlling. The serial comms features on most operating systems are not equipped to handle this since UART is expected to be integral part of the system. Well, USB has certainly changed that. Now not only the serial device can be unplugged (which is handled properly by protocols etc.) but the actual interface hardware too. Like ripping off the engine from your car while driving. For those reasons this issue is very hard for RXTX or any other serial comms library to handle. We could detect errors from kernel that indicate the UART has vanished and proceed to do automatic reopening of the serial port after some delay at the native lib. But: this has multiple issues, which probably will break user protocols and software. One of those is the fact that reopening the port could toggle its CTS/RTS/DTR/DSR signals causing unexpected trouble on user side. Other one is that we might end up in infinite loop of comm error <-> automatic reopening without notifying rxtx java side. Not elegant. Not proper. -- I'm proposing a following solution: We could implement a method to detect lost UART in event loop at native lib side and introduce a new Java side SerialPortEvent type UART_DISCONNECT. The native lib would send that event in case of error and proceed to automatically close the serial port and clear the invalid handles etc. (reset to fault free state). That would allow user code to gracefully handle these situations, by doing whatever is necessary to restore communications with their protocols etc. Usually that includes opening the serial port and doing some initializations. Those who choose to ignore that event, or not implement any handling for it, can continue to use RXTX as any other serial comms lib. But their software would still tumble and fall on UART disconnects - mostly caused by USB->UART bridges. Atleast, we'd have a method for implementing proper recovery if RXTX user chooses to do so. Beats duct tape+USB dongle combo anytime;) Feedback welcome :) -- I On Tue, 15 Sep 2009, Daniel Weinand wrote: Error 0x5 at ..\src\termios.c(2712): Access Denied Error 0x5 at ..\src\termios.c(517): Access Denied ... It is a known problem. The kernel driver isnt restoring the fd. See the previous post for what is required prior to being able to handle it in your code. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Wed Sep 16 05:42:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 16 Sep 2009 05:42:08 -0600 (MDT) Subject: [Rxtx] FTDI chipset speed - much slower? In-Reply-To: References: Message-ID: On Wed, 16 Sep 2009, Frings, Stefan, VF-DE wrote: > Hello David, > ? > Im not 100% sure, but I highly assume that the delays are produces by the > USB communication. USB transfers data in packets and there are large > buffers of several hundreds characters, similar to ethernet. There is no > real time communication. > ? > So when your software thinks that it has sent a character, this was not > the case. It was only put into a buffer and will appears at the end of > your USB2Serial cable after some time - I assume somewhat around 0,3ms. > ? > I noticed the same behavious with different USB2Serial adapters on Linux > with plain C programs (not anything around Java and RxTx). > ? I have seen some simple native C applications that do not inspect the LSR manage to send bytes closer to how an onboard UART does. In that case it was just two bytes being observed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Sep 16 05:55:14 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 16 Sep 2009 05:55:14 -0600 (MDT) Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby In-Reply-To: <0EB22ACB-0676-44DE-BBD3-A9D38CFD2E88@myller.com> References: <4AAF5838.7080707@gmail.com> <0EB22ACB-0676-44DE-BBD3-A9D38CFD2E88@myller.com> Message-ID: I think that will be fine. I'm not sure about all the corner cases with bluetooth dongles. On Wed, 16 Sep 2009, Ilkka Myller wrote: > Windows is not my primary platform, but I agree with Trent. > > I tested this too and noticed that ClearCommError() does not fail because > RXTX loses fd (why would it), but because fd seems to no longer exist, or > is reused, on kernel side. Resulting in access denied(5) error. > Definitely something RXTX has no control of. > Also the USB device re-registers itself, causing all it's previous file > handles invalidated. After few seconds after waking from sleep, new ones > can be created with CreateFile calls - as expected. > > FTDI chips can be reprogrammed not to do this reconnection cycle on USB > sleep (with mprog 3.5 software). I dont know how well Windows follows > that setting. Also Windows allows disabling USB power saving on specific > USB devices. > > After those settings, it entirely up to the USB driver to do the right > thing. .. which I'm not entirely sure it will - even if it's technically > possible to retain fd's over sleep the driver might still be hardwired to > reconnect the device on power save events. > > -- > > Basicly all these issues are about the fact that someone/something rips > off the UART hardware RXTX is controlling. The serial comms features on > most operating systems are not equipped to handle this since UART is > expected to be integral part of the system. Well, USB has certainly > changed that.? > Now not only the serial device can be unplugged (which is handled > properly by protocols etc.) but the actual interface hardware too. Like > ripping off the engine from your car while driving. > > For those reasons this issue is very hard for RXTX or any other serial > comms library to handle. We could detect errors from kernel that indicate > the UART has vanished and proceed to do automatic reopening of the serial > port after some delay at the native lib. But: this has multiple issues, > which probably will break user protocols and software. One of those is > the fact that reopening the port could toggle its CTS/RTS/DTR/DSR signals > causing unexpected trouble on user side. Other one is that we might end > up in infinite loop of comm error <-> automatic reopening without > notifying rxtx java side. Not elegant. Not proper. > > -- > > I'm proposing a following solution: > > We could implement a method to detect lost UART in event loop at native > lib side and introduce a new Java side SerialPortEvent type > UART_DISCONNECT.?The native lib would send that event in case of error > and proceed to automatically close the serial port and clear the invalid > handles etc. (reset to fault free state). > > That would allow user code to gracefully handle these situations, by > doing whatever is necessary to restore communications with their > protocols etc. Usually that includes opening the serial port and doing > some initializations. > > Those who choose to ignore that event, or not implement any handling for > it, can continue to use RXTX as any other serial comms lib. But their > software would still tumble and fall on UART disconnects - mostly caused > by USB->UART bridges. > > Atleast, we'd have a method for implementing proper recovery if RXTX user > chooses to do so. Beats duct tape+USB dongle combo anytime;) > > Feedback welcome :)? > > -- > I > > > > On Tue, 15 Sep 2009, Daniel Weinand wrote: > > Error 0x5 at ..\src\termios.c(2712): Access > Denied > > Error 0x5 at ..\src\termios.c(517): Access Denied > > ... > > > It is a known problem. ?The kernel driver isnt restoring the > fd. ?See the previous post for what is required prior to > being able to handle it in your code. > > > From tjarvi at qbang.org Wed Sep 16 20:10:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 16 Sep 2009 18:10:42 -0600 (MDT) Subject: [Rxtx] Fwd: [Patch] Implement new UART_DISCONNECT event (fwd) Message-ID: Attachments are pending. They got caught by the size restrictions. > L?hett?j?: Ilkka Myller > P?iv?ys: 17. syyskuuta 2009 0.14.50 UTC+3.00 > Vastaanottaja: "rxtx at qbang.org" > Aihe: [Patch] Implement new UART_DISCONNECT event > > > Summary: > > This patch adds support for new SerialPortEvent.UART_DISCONNECT event. > > Backwards compatibility: > > If RXTX user does not register event listener and request UART_DISCONNECT > events, the RXTX functions same as before. (=does not react to UART > disconnects - or behaviour is unspecified). > > Implementation: > > 1. The RXTX native lib eventLoop() checks for UART disconnection (for example > USB Adapter unplug/powersave) and sends UART_DISCONNECT event to interested > Java listeners. This happens as soon as serial ports file descriptor/handle > becomes invalid or points to no longer existing serial port driver io's. > Sometimes the UART drivers accept writes/reads few seconds after actual > disconnect (this is normal and depends on OS and the driver used). > > 2. The Java send_event() closes serial ports automatically and forwards the > UART_DISCONNECT event to user code/listener. > > 3. Subsequent calls to any RXTXPort IO function (except close() or > removeEventListener()) throws PortAlreadyClosedException which is subclass of > IOException --> no code changes necessary if IOExceptions are already handled > in user code. This is for backwards compatibility. > > 4. It's up to the user code to handle the proper recovery after receiving the > UART_DISCONNECT (usually involves trying to reopen the port and reinitialize > protocols) > > How UART disconnect is detected: > > eventLoop() uses conditionally defined CHECK_FD(int fd) function to check if > file descriptor points to valid (and existing) serial port. On windows this > means calling termios_check_fd() function and all others call > posix_check_fd() function. > > On linux/mac/other posix, CHECK_FD calls fstat, fcntl and ioctl (with > non-port-state-altering parameters) to check if file descriptor is valid and > device driver behind it responds properly. > > On windows, CHECK_FD calls GetCommState() to check if serial port handle is > still valid and port is accessible. > > If someone knows a better way (less overhead) to check if fd is valid, please > let me know:) Checking fd value >0 is not enough, since we have to detect if > UART driver actually responds even when we have fd > 0 too. > > Patch: > > The included patch is against CVS (@2009/09/16). > It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < > im-uart-disconnect1.patch' in rxtx-devel/src directory. > > The patch file does not include gnu/io/PortAlreadyClosedException.java, which > is included as separate attachment. > You must place this to rxtx-devel/src/gnu/io directory. > > Demonstration code: > > I've also included a simple demonstration code to test this feature. I've > tested it on Windows and on Mac OS X. > The SerialReconnectDemo(.java) writes few bytes to the serial port > continuously every 500ms. > If UART_DISCONNECT is received, it goes into reconnect() loop in separate > thread and tries to re-establish serial port connection. > If connection can be re-established, it continues operation normally. > It uses ReentrantLocks to properly synchronize serial port operations, which > is very useful with reconnect and writes --> if going to reconnect mode, > writes are blocked until connection is re-established. > > The demonstration code nicely survives from random disconnects of USB Serial > adapter. > > > Feedback: > > This is highly experimental implementation and details are likely to change. > Testing and any feedback is more than welcome. > Especially Trent, any thoughts? Am I missing something here? > > > > Thanks, > > -- > I > > > > > > > > From stefan.frings at vodafone.com Thu Sep 17 02:22:40 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Thu, 17 Sep 2009 08:22:40 +0200 Subject: [Rxtx] RXTX on Ubuntu 9.04 with lock in /var/lock/LCK..ttyS0 In-Reply-To: References: Message-ID: Hello petter, I installed the C library through using apt and I copied the jar file to the lib folder of my Java application. The I added myself to the dialout group. Nothing else. --- Good morning. Tanks for help me. I added the User and now with RXTX did not signal more trouble to lock the serial port, but my Java application can no longer capture the data (in my case shipped weight of an electronic scale). It is very strange, because Windows works normally, you know if Linux is needed any more setup RXTX to work well? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.frings at vodafone.com Thu Sep 17 02:25:56 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Thu, 17 Sep 2009 08:25:56 +0200 Subject: [Rxtx] FTDI chipset speed - much slower? Message-ID: Hello Ozgur, I can tell you a value from Silabs CP2102 chip. With a simple loopback connection on the serial end and a bitrate of 115200 (everything else left to the default settings), using Linux, the echo of 1-10 characters comes always back withing one milliseconds in a Java application using RxTxComm. I am not able to measure it more exactly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.frings at vodafone.com Thu Sep 17 02:31:35 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Thu, 17 Sep 2009 08:31:35 +0200 Subject: [Rxtx] RxTx handling disconnected USB devices Message-ID: Hello Ilkka, I highly appreciate your recommendation. The Java application should decide what to do when the device gets disconnected. When I disconnect /dev/ttyUSB0 and then reconnect it, I want to be able to re-open that port. Currently, this is not the case, because RxTxComm does not close it when I disconnect the device. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Thu Sep 17 02:44:24 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 17 Sep 2009 09:44:24 +0300 Subject: [Rxtx] [Patch] New feature: Implemented UART_DISCONNECT event Message-ID: <6E51B6F1-41C3-4FD5-B4A9-CBFD4AF83C85@myller.com> Summary: This patch implements new SerialPortEvent.UART_DISCONNECT event. Backwards compatibility: If RXTX user does not register event listener and request UART_DISCONNECT events, the RXTX functions same as before. (=does not react to UART disconnects - or behaviour is unspecified). Implementation: 1. The RXTX native lib eventLoop() checks for UART disconnection (for example USB Adapter unplug/powersave) and sends UART_DISCONNECT event to interested Java listeners. This happens as soon as serial ports file descriptor/handle becomes invalid or points to no longer existing serial port driver io's. Sometimes the UART drivers accept writes/ reads few seconds after actual disconnect (this is normal and depends on OS and the driver used). 2. The Java send_event() closes serial ports automatically and forwards the UART_DISCONNECT event to user code/listener. 3. Subsequent calls to any RXTXPort IO function (except close() or removeEventListener()) throws PortAlreadyClosedException which is subclass of IOException --> no code changes necessary if IOExceptions are already handled in user code. This is for backwards compatibility. 4. It's up to the user code to handle the proper recovery after receiving the UART_DISCONNECT (usually involves trying to reopen the port and reinitialize protocols) How UART disconnect is detected: eventLoop() uses conditionally defined CHECK_FD(int fd) function to check if file descriptor points to valid (and existing) serial port. On windows this means calling termios_check_fd() function and all others call posix_check_fd() function. On linux/mac/other posix, CHECK_FD calls fstat, fcntl and ioctl (with non-port-state-altering parameters) to check if file descriptor is valid and device driver behind it responds properly. On windows, CHECK_FD calls GetCommState() to check if serial port handle is still valid and port is accessible. If someone knows a better way (less overhead) to check if fd is valid, please let me know:) Checking fd value >0 is not enough, since we have to detect if UART driver actually responds even when we have fd > 0 too. Patch: The patch file is against CVS (@2009/09/16). It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < im- uart-disconnect1.patch' in rxtx-devel/src directory. The patch file does not include gnu/io/ PortAlreadyClosedException.java, which is included as separate file. You must place this to rxtx-devel/src/gnu/io directory. Due to mailing list restrictions, the attachments are inside .tar.gz archive. Demonstration code: I've also included a simple demonstration code to test this feature. I've tested it on Windows and on Mac OS X. The SerialReconnectDemo(.java) writes few bytes to the serial port continuously every 500ms. If UART_DISCONNECT is received, it goes into reconnect() loop in separate thread and tries to re-establish serial port connection. If connection can be re-established, it continues operation normally. It uses ReentrantLocks to properly synchronize serial port operations, which is very useful with reconnect and writes --> if going to reconnect mode, writes are blocked until connection is re-established. The demonstration code nicely survives from random disconnects of USB Serial adapter. Feedback: This is highly experimental implementation and details are likely to change. Testing and any feedback is more than welcome. Especially Trent, any thoughts? Am I missing something here? Thanks, -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im-uart-disconnect-1.tar.gz Type: application/x-gzip Size: 11834 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Tue Sep 1 02:38:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 1 Sep 2009 02:38:40 -0600 (MDT) Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks Ilkka The problem should be resolved (confirmed from two locations). I'll be trying to hunt down a Snow Leopard box tomorrow evening as well. On Tue, 1 Sep 2009, Ilkka Myller wrote: > Hi, > > CVS server is reachable, but when trying anonymous login it replies: > > " > Fatal error, aborting. > anonymous: no such system user > " > > It seems that the anonymous cvs account is not yet properly configured on the > new system. > > -- > I > >> On Mon, 31 Aug 2009, Trent Jarvi wrote: >> >> The server has been beemed to another location for those experiencing >> routing problems. >> >> in bash: >> >> export CVSROOT=:pserver:anonymous at qbang.org:2401/var/cvs/cvsroot >> cvs login (no passwd) >> cvs co -r commapi-0-0-1 rxtx-devel >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Tue Sep 1 03:05:59 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 12:05:59 +0300 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks, The new CVS server works well :) I can also confirm that latest CVS version builds properly with unmodified Snow Leopard (Mac OS X 10.6) system: Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 gcc version 4.2.1 (Apple Inc. build 5646) Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) --> Resulting JNI library (Universal Binary): i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = 9d15fc488b301da8bf65b2c9456a7bbb --> Resulting JAR: RXTXComm.jar / 60942 bytes MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 Atleast it builds.. and probably works too. I have not tested that yet. -- I Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > The problem should be resolved (confirmed from two locations). I'll > be trying to hunt down a Snow Leopard box tomorrow evening as well. From jimmy.lee at emotum.com Tue Sep 1 05:07:19 2009 From: jimmy.lee at emotum.com (Jimmy Lee [emotum]) Date: Tue, 1 Sep 2009 21:07:19 +1000 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: <112685a90909010407i6054acb5tc2b12196797bfaf1@mail.gmail.com> Could we access to the binaries? Please :) 2009/9/1 Ilkka Myller > Thanks, > > The new CVS server works well :) > > I can also confirm that latest CVS version builds properly with unmodified > Snow Leopard (Mac OS X 10.6) system: > > Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_I386 i386 > gcc version 4.2.1 (Apple Inc. build 5646) > Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) > > > --> Resulting JNI library (Universal Binary): > > i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes > > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 > librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc > > MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = > 9d15fc488b301da8bf65b2c9456a7bbb > > > --> Resulting JAR: > > RXTXComm.jar / 60942 bytes > > MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 > > > > Atleast it builds.. and probably works too. I have not tested that yet. > > -- > I > > Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > > The problem should be resolved (confirmed from two locations). I'll be >> trying to hunt down a Snow Leopard box tomorrow evening as well. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Tue Sep 1 06:21:28 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Tue, 1 Sep 2009 08:21:28 -0400 (EDT) Subject: [Rxtx] Snow Leopard binaries Message-ID: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> +1 for binaries - pretty please with sugar on top... -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com From fredm at alum.mit.edu Tue Sep 1 06:24:17 2009 From: fredm at alum.mit.edu (Fred G. Martin) Date: Tue, 1 Sep 2009 08:24:17 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> Message-ID: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> You can find one here: http://iharder.sourceforge.net/current/java/ Also, you need to add yourself (any rxtx user) to the uucp group. Niutils don't exist, but dscl is a replacement. There is info for using it here: http://aplawrence.com/MacOSX/directory_services.html Fred On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Tue Sep 1 07:03:37 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Tue, 1 Sep 2009 18:33:37 +0530 Subject: [Rxtx] Help for RXTX on mac Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time I am able to read the device but on second time, it hangs on COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then it was showing the PortInUseException, I replaced the RXTX library to 2.2Pre1 so it is showing this problem. Is this is a problem with RXTX on Mac? Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: From ilkka at myller.com Tue Sep 1 07:57:06 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 16:57:06 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:02:31 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:02:31 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:43:49 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:43:49 +0300 Subject: [Rxtx] Help for RXTX on mac In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE@myller.com> Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Arseneau at Sun.COM Tue Sep 1 08:51:32 2009 From: Eric.Arseneau at Sun.COM (Eric Arseneau) Date: Tue, 01 Sep 2009 07:51:32 -0700 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24@sun.com> Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 09:24:30 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 18:24:30 +0300 Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D@myller.com> Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Thu Sep 3 02:50:16 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Thu, 3 Sep 2009 10:50:16 +0200 Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s From Kapil_Gupta at hcl.in Thu Sep 3 06:52:21 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:22:21 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From Kapil_Gupta at hcl.in Thu Sep 3 07:15:19 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:45:19 +0530 Subject: [Rxtx] Rxtx Digest, Vol 25, Issue 3 In-Reply-To: References: Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C50BB@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi myller, I have attached the code with the mail. Please help me if I am doing something wrong in it. Thanks & Regards, Kapil Gupta -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of rxtx-request at qbang.org Sent: Thursday, September 03, 2009 4:15 PM To: rxtx at qbang.org Subject: Rxtx Digest, Vol 25, Issue 3 Send Rxtx mailing list submissions to rxtx at qbang.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qbang.org/mailman/listinfo/rxtx or, via email, send a message with subject or body 'help' to rxtx-request at qbang.org You can reach the person managing the list at rxtx-owner at qbang.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Rxtx digest..." Today's Topics: 1. Re: Snow Leopard binaries (Ilkka Myller) 2. Re: Snow Leopard binaries (Ilkka Myller) 3. Re: Help for RXTX on mac (Ilkka Myller) 4. Re: Snow Leopard binaries (Eric Arseneau) 5. Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters (Ilkka Myller) 6. RXTX multiple crashes (Kjetil ?ster?s) 7. RXTX 2.2Pre + MacMini+ Deadlock while second time port open (Kapil Gupta) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Sep 2009 16:57:06 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 1 Sep 2009 17:02:31 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <55EC133D-DC83-45A3-849C-02714904D580 at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 1 Sep 2009 17:43:49 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Help for RXTX on mac Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Tue, 01 Sep 2009 07:51:32 -0700 From: Eric Arseneau Cc: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24 at sun.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 1 Sep 2009 18:24:30 +0300 From: Ilkka Myller To: rxtx Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Thu, 3 Sep 2009 10:50:16 +0200 From: Kjetil ?ster?s To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s ------------------------------ Message: 7 Date: Thu, 3 Sep 2009 18:22:21 +0530 From: Kapil Gupta To: "rxtx at qbang.org" Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059 at NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset="us-ascii" Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: ------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx End of Rxtx Digest, Vol 25, Issue 3 *********************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From ilkka at myller.com Thu Sep 3 11:17:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 3 Sep 2009 20:17:27 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <4520677F-E8F0-46F5-B4AD-3AD3A7C2AED3@myller.com> Hi Kapil, The code is incomplete and I did not find anything I could to test/ debug with this. I also tried to find the actual serial port opening, but found only a call to missing method which creates the SerialPort object (?): serialPort = getSerialPortConnection( COMPort, this.readEvent.getDeviceName(), SerialCommConfig.DEVICE1[SerialCommConfig.TIMEOUT], SerialCommConfig.DEVICE1[SerialCommConfig.BAUDRATE], SerialCommConfig.DEVICE1[SerialCommConfig.DATABITS], SerialCommConfig.DEVICE1[SerialCommConfig.STOPBITS], SerialCommConfig.DEVICE1[SerialCommConfig.PARITY] ); The class SerialCommConfig is missing too. If this is a part of the actual code you are using, please note that you are not actually closing the serial port. The call to close() method is commented out: try { // serialPort.close(); } catch (Exception ex) { ex.printStackTrace(); } Re-opening of the serial port wont work if you haven't properly closed it first. -- I > > I am using RXTX on Macintosh to communicate to my device. First time > the device responds well but on second time, it hangs on > COMPort.open (name, timeout). > > I have attached the source code in a file. Please help me. > > Thanks & Best Regards, > Kapil -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorton at intellimec.com Thu Sep 3 11:37:55 2009 From: dmorton at intellimec.com (Daniel Morton) Date: Thu, 3 Sep 2009 13:37:55 -0400 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. (I haven't tried previous version though). Daniel Morton Java/J2EE Developer Tel +1 519.745.8887 x4331 Email dmorton at intellimec.com www.intellimec.com | www.iLane.com | www.drivesync.com Intelligent Mechatronic Systems Inc. 435 King Street North Waterloo, ON N2J 2Z5 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s Sent: Thursday, September 03, 2009 4:50 AM To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. From alexanderkiel at gmx.net Fri Sep 4 02:29:15 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 10:29:15 +0200 Subject: [Rxtx] Official Javadoc Location Message-ID: <1252052955.4025.80.camel@T61-KIEL> Hi List, I wasn't able to find an official location of RXTX Javadoc accessible over HTTP. Maybe someone can link me to it. If there is no such location, I would like to see one. I like to link from my own Javadoc to such a location. Thanks Alexander - e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:19:25 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:19:25 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> Message-ID: <1252055965.4025.84.camel@T61-KIEL> Hi Michael, thanks for the pointer. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 09:48 +0100, Michael Tandy wrote: > RxTx javadoc: http://users.frii.com/jarvi/rxtx/doc/index.html > Javax interface RxTx duplicates javadoc: > http://java.sun.com/products/javacomm/reference/api/index.html > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:22:14 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:22:14 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> Message-ID: <1252056134.4025.87.camel@T61-KIEL> Hi Eike, thanks, but I need a direct package pointer so that Javadoc will link the gnu.io packages automatically to the right location. Michael has pointed me to http://users.frii.com/jarvi/rxtx/doc/index.html which has the gnu.io packages. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 11:04 +0200, Eike Hinderk J?rrens wrote: > Hi Alexander, > it seems to me that RXTX is implementing this API: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Kind regards, > Eike > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kjetilos at gmail.com Fri Sep 4 03:43:41 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 11:43:41 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> Message-ID: <7a803d460909040243ke4449ecucbe2cd8b15761746@mail.gmail.com> Hi Daniel, This is interesting, what type of application are you making? Is there a lot of signaling on different COM ports at the same time in your application? In our application we have 11 devices connected to different COM ports, 9 of these are in active use when the application is running. I'm wondering how to use the RXTX library version 2.1.7 in this scenario without causing it to crash. After adding more signaling on the COM ports in our application we have now experienced other crashes and it is natural to think that it has something to do with our way of using RXTX from several threads at the same time. So my question is are there any methods like read/write/flush/close that are not thread safe and should be handled with care? And similarly is the RXTXPort.SerialInputStream and RXTXPort.SerialOutputStream thread safe? 2009/9/3 Daniel Morton : > I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. ?(I haven't tried previous version though). > > Daniel Morton > Java/J2EE Developer > > Tel ? ?+1 519.745.8887 x4331 > Email ? ?dmorton at intellimec.com > > > www.intellimec.com ?| ?www.iLane.com ?| ?www.drivesync.com > > > > Intelligent Mechatronic Systems Inc. > 435 King Street North Waterloo, ON N2J 2Z5 > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s > Sent: Thursday, September 03, 2009 4:50 AM > To: rxtx at qbang.org > Subject: [Rxtx] RXTX multiple crashes > > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x7d0d] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0ce75800): ?JavaThread "Y Worker" daemon > [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 > > Registers: > EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 > ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 > EIP=0x10007d0d, EFLAGS=0x00010202 > > Top of Stack: (sp=0x0d7ff6d8) > 0x0d7ff6d8: ? 0d7ff700 00000000 00000000 00000000 > 0x0d7ff6e8: ? 02a2eae8 00000123 00002958 0d7ff718 > 0x0d7ff6f8: ? 7c830887 7c90d28a 7c8664b5 00000e2c > 0x0d7ff708: ? 00002958 00000000 00000000 7c90cffa > 0x0d7ff718: ? 7c809bdb 00002958 0d7ff758 00000e40 > 0x0d7ff728: ? 00002958 02bd0468 0ce75800 080e4ee0 > 0x0d7ff738: ? 00000000 00000000 00000000 00000000 > 0x0d7ff748: ? 00000000 00000000 00000014 7c90d09a > > Instructions: (pc=0x10007d0d) > 0x10007cfd: ? 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 > 0x10007d0d: ? 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 > > > Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x7d0d] > J ?gnu.io.RXTXPort.nativeDrain(Z)Z > J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > ... > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x9c55] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0cddf400): ?JavaThread "XXX Worker" daemon > [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 > > Registers: > EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 > ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 > EIP=0x10009c55, EFLAGS=0x00010206 > > Top of Stack: (sp=0x0bb8f830) > 0x0bb8f830: ? 00000000 00000000 c0000005 00000000 > 0x0bb8f840: ? 00000000 00f1f0a5 00000002 00000000 > 0x0bb8f850: ? 003a0100 0001003f 0bb8fb20 0b9ff918 > 0x0bb8f860: ? 00000000 00000000 0bb8fb68 0bb8fb20 > 0x0bb8f870: ? 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 > 0x0bb8f880: ? 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 > 0x0bb8f890: ? 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 > 0x0bb8f8a0: ? 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 > > Instructions: (pc=0x10009c55) > 0x10009c45: ? 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff > 0x10009c55: ? 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 > > > Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x9c55] > C ?[rxtxSerial.dll+0xa05e] > J ?gnu.io.RXTXPort.readByte()I > J ?gnu.io.RXTXPort$SerialInputStream.read()I > J ?java.io.FilterInputStream.read()I > ... > > -- > Kjetil ?ster?s > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kjetil ?ster?s From tjarvi at qbang.org Fri Sep 4 06:00:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Sep 2009 06:00:40 -0600 (MDT) Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x7d0d] > J gnu.io.RXTXPort.nativeDrain(Z)Z > J gnu.io.RXTXPort$SerialOutputStream.flush()V > Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x9c55] > C [rxtxSerial.dll+0xa05e] > J gnu.io.RXTXPort.readByte()I > J gnu.io.RXTXPort$SerialInputStream.read()I RXTX 2.1-7 has concurrency issues that will show upon multicore systems. These should be resolved in the 2.2 pre release. A user application could synchronize the read/write/open/close calls while using 2.1 to avoid the concurrency issue. The flush is probably following a write while the readByte is coming from read(byte b). The bugs existed in rxtx for a long time. I assume changes in the JVM and the presence of multicore systems exposed the issues. -- Trent Jarvi tjarvi at qbang.org From kjetilos at gmail.com Fri Sep 4 06:33:33 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 14:33:33 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <7a803d460909040533n1caf240y8168477a578bc45c@mail.gmail.com> Den 4. september 2009 14.00 skrev Trent Jarvi f?lgende: > > > On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > >> Hi >> >> We are using RXTX version 2.1.7 actively and lately we are having some >> issues with the RXTX library crashing. We are running a windows xp >> system with multiple COM ports where each COM port have a serial >> device connected. Lately we have increased the amount of signaling >> done over the COM ports and we are experiencing several odd crashes. I >> tried to search the mailinglist for something similar but was unable >> to find anything. At one time the RXTX crashed in the >> gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the >> gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack >> traces if someone is interested in having a look. Has anyone seen the >> same crashes? and does anyone know what can cause such crash? >> >> >> Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x7d0d] >> J ?gnu.io.RXTXPort.nativeDrain(Z)Z >> J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > >> Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x9c55] >> C ?[rxtxSerial.dll+0xa05e] >> J ?gnu.io.RXTXPort.readByte()I >> J ?gnu.io.RXTXPort$SerialInputStream.read()I > > > RXTX 2.1-7 has concurrency issues that will show upon multicore systems. > These should be resolved in the 2.2 pre release. ?A user application could > synchronize the read/write/open/close calls while using 2.1 to avoid the > concurrency issue. > > The flush is probably following a write while the readByte is coming from > read(byte b). > > The bugs existed in rxtx for a long time. ?I assume changes in the JVM and > the presence of multicore systems exposed the issues. > Ok, so we should look more into using a newer version of RXTX. The current version from the webpage is 2.2pre2, what is the stability status of this version. Is it good enough for use in a production environment? -- Kjetil ?ster?s From martinezrodolfo at gmail.com Fri Sep 4 13:39:57 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Fri, 4 Sep 2009 15:09:57 -0430 Subject: [Rxtx] Problem with data available event Message-ID: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Hello list members. I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a serial port USB adapter to communicate with an electronical inmunoassay analyzer. The program works porperly with one model of the analyzer series. It defines a protocol which every message sent should be replied with an ACK in order to continue with the communication. Now we are trying to communicate with another model of the same brand and series wich in theory should be much of the same of what was previously done. Unfortunately, that is not the case. The problem with this connection is that it never fires the Data Available serial port event. Is like if nothing was being received in the input stream. The following code always prints zero when the equipment should be transmitting. ----------------------- beginning of sample code ---------------------------------- SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", 10000); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); int len = 0; byte[] readBuffer = new byte[8]; while (true) { len = in.read(readBuffer); System.out.println(len); writer.writeACK(); // writing ACK to analyzer } ----------------------- end of sample code ------------------------------------------ We know that the analyzer is transmitting because HyperTerminal does shows the proper output. In fact, after running the above code and connecting via Hyperterminal all data is received in one block. Is like the data sent from the analyzer is being held somewhere in the way. Sniffing at the serial port, noticed that IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this helps to find what might be wrong or not, but here they are: On Hyperterminal: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 XonLimit:80 XoffLimit:200 On Java: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 XonLimit:0 XoffLimit:0 Thanks in advance for your help. Rodolfo M From ilkka at myller.com Sat Sep 5 04:36:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 5 Sep 2009 13:36:27 +0300 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <121198EE-65A4-463B-ACC7-29FFB9855B2C@myller.com> Hi Rodolfo, By default RXTX does not enable any flow control for the serial port. Please check what flow control you have active in HyperTerminal when you are able to receive data and then use the same flow control with RXTX serial port: serialPort.setFlowControlMode(int flowcontrol); Possible flowcontrol flags are (from SerialPort class) FLOWCONTROL_NONE FLOWCONTROL_RTSCTS_IN FLOWCONTROL_RTSCTS_OUT FLOWCONTROL_XONXOFF_IN FLOWCONTROL_XONXOFF_OUT For example, you can try enabling RTS/CTS hardware flow control. Note the bitwise OR operator ' | ': serialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Also if your device requires RTS/CTS flow control make sure you have fully connected serial cable (not just RX, TX, GND for example, but also RTS, CTS, DTR). One thing you might want to check is the state of DTR (Data Terminal Ready). Some devices wait for the DTR signal before they send any data. You can enable or disable DTR signal (high/low) with: serialPort.setDTR( boolean state ); -- I > Hello list members. > > I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a > serial port USB adapter to communicate with an electronical > inmunoassay analyzer. The program works porperly with one model of the > analyzer series. It defines a protocol which every message sent should > be replied with an ACK in order to continue with the communication. > Now we are trying to communicate with another model of the same brand > and series wich in theory should be much of the same of what was > previously done. Unfortunately, that is not the case. The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. > > ----------------------- beginning of sample code > ---------------------------------- > SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", > 10000); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > InputStream in = serialPort.getInputStream(); > OutputStream out = serialPort.getOutputStream(); > > int len = 0; > byte[] readBuffer = new byte[8]; > while (true) { > len = in.read(readBuffer); > System.out.println(len); > > writer.writeACK(); // writing ACK to analyzer > } > ----------------------- end of sample code > ------------------------------------------ > > We know that the analyzer is transmitting because HyperTerminal does > shows the proper output. In fact, after running the above code and > connecting via Hyperterminal all data is received in one block. Is > like the data sent from the analyzer is being held somewhere in the > way. Sniffing at the serial port, noticed that > IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this > helps to find what might be wrong or not, but here they are: > > On Hyperterminal: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 > XonLimit:80 XoffLimit:200 > > On Java: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 > XonLimit:0 XoffLimit:0 > > > Thanks in advance for your help. > Rodolfo M > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.weber99 at gmx.net Sun Sep 6 13:51:12 2009 From: karl.weber99 at gmx.net (Karl Weber) Date: Sun, 6 Sep 2009 21:51:12 +0200 Subject: [Rxtx] Cannot create lock file Message-ID: <200909062151.12228.karl.weber99@gmx.net> Hi, I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an opensuse repository as well as from the homepage of the rxtx project. I have already added the user to the group uucp, however, it does not have any effect. What else do I have to do to make it work? (It does work with user root, though.) The error message is: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL Thanks in advance, Karl From tjarvi at qbang.org Sun Sep 6 13:51:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 6 Sep 2009 13:51:42 -0600 (MDT) Subject: [Rxtx] Cannot create lock file In-Reply-To: <200909062151.12228.karl.weber99@gmx.net> References: <200909062151.12228.karl.weber99@gmx.net> Message-ID: On Sun, 6 Sep 2009, Karl Weber wrote: > Hi, > > I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an > opensuse repository as well as from the homepage of the rxtx project. > > I have already added the user to the group uucp, however, it does not have > any effect. What else do I have to do to make it work? (It does work with > user root, though.) > > The error message is: > > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to > create lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > > Thanks in advance, Karl Look at the group that owns /var/lock with ls -ld /var/lock The following should work as a user when they are in the correct group: touch /var/lock/test && rm -f /var/lock/test -- Trent Jarvi tjarvi at qbang.org From Luca.Catoni at sysdat.it Mon Sep 7 06:32:42 2009 From: Luca.Catoni at sysdat.it (Luca Catoni) Date: Mon, 7 Sep 2009 14:32:42 +0200 Subject: [Rxtx] time-out implementation Message-ID: I need to implement a simple timer class to manage time-out in my RS-232 serial communication with a remote device using the rxtx library. The functions that the timer should have are start(), and reset() and start() method must throw an exception (TimeoutException) when it expires. I am not an expert in concurrent programming and I do not have much knowledge on threads. myTimer.setExpirationTime(myvalue); ? public void serialEvent(SerialPortEvent event) { if (event.getEventType() == SerialPortEvent.OUTPUT_BUFFER_EMPTY) { // transmission ? out.write(?); try{ myTimer.start(); }catch(TimeoutException te){ myTimer.reset(); ? } ? if (event.getEventType() == SerialPortEvent.DATA_AVAILABLE) { // receiving in.read(?); if (mycondition){ myTimer.stop();//ok, timer NOT expired myTimer.reset();//now I can call start() method again in //transmission to restart my timer when I //have to transmit next data } Can anyone help me to implement the class MyTimer? thanks in advance. -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Mon Sep 7 06:49:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Mon, 7 Sep 2009 18:19:24 +0530 Subject: [Rxtx] 2.2Pre + MacMini+ Deadlock while second time port Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E22FB6F@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, Please find the updated code (close call was commented by mistake). This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From michael.erskine at ketech.com Mon Sep 7 09:13:03 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 7 Sep 2009 16:13:03 +0100 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Rodolfo Mart?nez > Subject: [Rxtx] Problem with data available event > The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. Hi Rodolfo, The sample code you provided doesn't implement or register any event listeners. Regards, Michael Erskine. From martinezrodolfo at gmail.com Mon Sep 7 10:21:22 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Mon, 7 Sep 2009 11:51:22 -0430 Subject: [Rxtx] Problem with data available event In-Reply-To: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> Message-ID: <30eacee0909070921l7f285765ue2c661963183fd2b@mail.gmail.com> On Mon, Sep 7, 2009 at 10:43 AM, Michael Erskine wrote: > Hi Rodolfo, > The sample code you provided doesn't implement or register any event listeners. > > Regards, > Michael Erskine. Hi Michael, I didn't write the event listeners declaration on the sample code for simplicity, but I do implement them on my real code. I should have mentioned it on the sample code anyway... my bad. I haven't had access to the device I'm trying to connect, but tomorrow will. And hope that with the explanation of Ilkka Myller will succeed this time. Thanks for your attention. Rodolfo M From ajmas at sympatico.ca Mon Sep 7 16:58:13 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 7 Sep 2009 18:58:13 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" I noticed in the page you posted posted you indicated that you patched two files. Did you submit the changes to Jarvi, so they could be included in the main code branch? Andr? From tjarvi at qbang.org Mon Sep 7 16:57:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Sep 2009 16:57:53 -0600 (MDT) Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On Mon, 7 Sep 2009, Andre-John Mas wrote: > > On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > >> Sorry, my rudeness was not intentional (a typo). >> Lets try again.. ;) >> >> "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > I noticed in the page you posted posted you indicated that you patched two > files. Did you submit the changes to Jarvi, so they could be included in the > main code branch? > Hi Andr? Ilkka is working with us to get changes in. I'm not sure about those two patches which may already be in CVS. I'll let him answer that. I've given him write access to CVS and asked him to cc the list non whitespace changes when they are ready. Right now he is asking questions off the list regarding cleaning up the Mac and w32 build files. -- Trent Jarvi tjarvi at qbang.org From nsp25 at cornell.edu Mon Sep 7 21:17:45 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Mon, 7 Sep 2009 23:17:45 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: (Sorry if this is a double post, but I sent my original message without subscribing, and since this is an urgent problem, I thought I'd resend after subscribing to bypass the moderator limbo zone) Hi all, I've asked my question on StackOverflow already, so rather than copy-paste the question here, I'd like to redirect you there . Short version, I am no longer able to receive anything over RS-232 with RXTX, but other programs work fine. I'm definitely sending things, because when I connect with a different program, all the responses to the commands I sent via RXTX arrive all at once. Everything was fine in the spring, so what could have happened? Windows update? -Nate -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.j.tandy at warwick.ac.uk Tue Sep 8 01:30:48 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Tue, 8 Sep 2009 08:30:48 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> OK, so: 1. It worked in spring but has stopped doing so and 2. The data all arrives at once when you start hyperterminal. Is it possible you're using a different serial cable to connect to the device, compared to the one you were using in spring? If so, the issue might be hardware flow control - that is, your device might be buffering data because it can't transmit it until your computer sets 'DTR' or 'RTS' or something like that. One way of bypassing hardware flow control is by using cables which cross over certain wires so that the right signals are always being sent; it's possible your old cable had these connections but your current cable doesn't have them. If you can find the old cable, you could put it back in and see if that fixes things? 2009/9/8 Nathaniel S. Parsons : > (Sorry if this is a double post, but I sent my original message without > subscribing, and since this is an urgent problem, I thought I'd resend after > subscribing to bypass the moderator limbo zone) > > Hi all, > > I've asked my question on StackOverflow already, so rather than copy-paste > the question here, I'd like to redirect you there. > > Short version, I am no longer able to receive anything over RS-232 with > RXTX, but other programs work fine. I'm definitely sending things, because > when I connect with a different program, all the responses to the commands I > sent via RXTX arrive all at once. > > Everything was fine in the spring, so what could have happened? Windows > update? > > -Nate > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Tue Sep 8 01:50:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 8 Sep 2009 10:50:33 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <111FEC9A-26BA-435C-BABC-314C7E4F23E5@myller.com> Hi all, Patches applied to the 2.1.7 binaries distributed by Robert Harder (http://iharder.sourceforge.net/current/java/ ) are already in the 2.2. Actually in 2.2 the issue with integer types handling seems to be fixed even more extensively than that single patch to 2.1.7 originally did. And yes, Trent has granted me CVS commit access. Thank you. First thing I'm going to focus on is the code quality and clean up: unused variables, invalid pointer usage etc.. Most of this just causing compile warnings - some harmless and some have potential for causing runtime problems. Instead of just blindly committing new changes to CVS, I've been discussing with Trent about the way things have been done in the RXTX CVS before. (how to handle white space patches, what needs to be discussed with the list first, proper locations for new files/ directories/subprojects, "the way things are done in RXTX"). But patches are coming and bugs will be fixed. I hope everyone will continue to submit the bugs they discover to this mailing list. Most important thing is to provide enough info (code;) so that the issue can be duplicated and eventually fixed. -- I > > > On Mon, 7 Sep 2009, Andre-John Mas wrote: >> >> I noticed in the page you posted posted you indicated that you >> patched two files. Did you submit the changes to Jarvi, so they >> could be included in the main code branch? >> > > Ilkka is working with us to get changes in. I'm not sure about > those two patches which may already be in CVS. I'll let him answer > that. > > I've given him write access to CVS and asked him to cc the list non > whitespace changes when they are ready. Right now he is asking > questions off the list regarding cleaning up the Mac and w32 build > files. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 15:35:19 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 17:35:19 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: Thanks for the response. I'll try to get to the electronics store tomorrow to get more serial cables, even if it isn't the problem. I am using a different serial cable than I was in the spring. It's actually a Male/Female cable with a female-female adapter since the old cables aren't around anymore. The hardware's manual says nothing except to use a "Straight cable" but I figured that if it worked in HyperTerminal, it should work in RXTX, right? Anyways, I've also noticed some things that are different between HyperTerminal, RXTX, and a separate program I found that communicates with the device (but doesn't do what I want, which is why I'm rolling my own program) HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and DTR indicators are green Other program - not sure what settings it thinks it's using, but only SPM's RTS indicator is green RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators are on. >From Serial Port Monitor's help files (paraphrased): the indicators display the state of the serial control lines RTS - Request To Send CTS - Clear To Send DTR - Data Terminal Ready Could this be related to the problem? -Nate On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > OK, so: > > 1. It worked in spring but has stopped doing so and > 2. The data all arrives at once when you start hyperterminal. > > Is it possible you're using a different serial cable to connect to the > device, compared to the one you were using in spring? > > If so, the issue might be hardware flow control - that is, your device > might be buffering data because it can't transmit it until your > computer sets 'DTR' or 'RTS' or something like that. > > One way of bypassing hardware flow control is by using cables which > cross over certain wires so that the right signals are always being > sent; it's possible your old cable had these connections but your > current cable doesn't have them. If you can find the old cable, you > could put it back in and see if that fixes things? > > > 2009/9/8 Nathaniel S. Parsons : > > (Sorry if this is a double post, but I sent my original message without > > subscribing, and since this is an urgent problem, I thought I'd resend > after > > subscribing to bypass the moderator limbo zone) > > > > Hi all, > > > > I've asked my question on StackOverflow already, so rather than > copy-paste > > the question here, I'd like to redirect you there. > > > > Short version, I am no longer able to receive anything over RS-232 with > > RXTX, but other programs work fine. I'm definitely sending things, > because > > when I connect with a different program, all the responses to the > commands I > > sent via RXTX arrive all at once. > > > > Everything was fine in the spring, so what could have happened? Windows > > update? > > > > -Nate > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 18:57:58 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 20:57:58 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: I added a call to setRTS() but nothing changed in Serial Port Monitor, no matter what the argument was. Is this a bug, or did I call the wrong function? I tried to find the c code behind this function, and I think I found it in rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong to me. Am I looking at the right function or is the problem somewhere else? -Nate On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons wrote: > Thanks for the response. I'll try to get to the electronics store tomorrow > to get more serial cables, even if it isn't the problem. > > I am using a different serial cable than I was in the spring. It's actually > a Male/Female cable with a female-female adapter since the old cables aren't > around anymore. The hardware's manual says nothing except to use a "Straight > cable" but I figured that if it worked in HyperTerminal, it should work in > RXTX, right? > > Anyways, I've also noticed some things that are different between > HyperTerminal, RXTX, and a separate program I found that communicates with > the device (but doesn't do what I want, which is why I'm rolling my own > program) > > HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and > DTR indicators are green > Other program - not sure what settings it thinks it's using, but only SPM's > RTS indicator is green > RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators > are on. > > From Serial Port Monitor's help files (paraphrased): the indicators display > the state of the serial control lines > > RTS - Request To Send > CTS - Clear To Send > DTR - Data Terminal Ready > > Could this be related to the problem? > > -Nate > > > On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > >> OK, so: >> >> 1. It worked in spring but has stopped doing so and >> 2. The data all arrives at once when you start hyperterminal. >> >> Is it possible you're using a different serial cable to connect to the >> device, compared to the one you were using in spring? >> >> If so, the issue might be hardware flow control - that is, your device >> might be buffering data because it can't transmit it until your >> computer sets 'DTR' or 'RTS' or something like that. >> >> One way of bypassing hardware flow control is by using cables which >> cross over certain wires so that the right signals are always being >> sent; it's possible your old cable had these connections but your >> current cable doesn't have them. If you can find the old cable, you >> could put it back in and see if that fixes things? >> >> >> 2009/9/8 Nathaniel S. Parsons : >> > (Sorry if this is a double post, but I sent my original message without >> > subscribing, and since this is an urgent problem, I thought I'd resend >> after >> > subscribing to bypass the moderator limbo zone) >> > >> > Hi all, >> > >> > I've asked my question on StackOverflow already, so rather than >> copy-paste >> > the question here, I'd like to redirect you there. >> > >> > Short version, I am no longer able to receive anything over RS-232 with >> > RXTX, but other programs work fine. I'm definitely sending things, >> because >> > when I connect with a different program, all the responses to the >> commands I >> > sent via RXTX arrive all at once. >> > >> > Everything was fine in the spring, so what could have happened? Windows >> > update? >> > >> > -Nate >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Tue Sep 8 21:54:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 21:54:26 -0600 (MDT) Subject: [Rxtx] rxtx is moving to the clouds Message-ID: rxtx is moving onto a cloud server. You may notice short outages as things move around. So far the following is done. http://rxtx.qbang.org (will redirect rxtx.org there for 2.2) http://bugzilla.qbang.org (bugs) The mail-list is tomorrow night. CVS and FTP will be last. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 8 22:03:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 22:03:26 -0600 (MDT) Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: On Tue, 8 Sep 2009, Nathaniel S. Parsons wrote: > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? Hi Nathaniel, That depends upon what you are running. WinCE is for embedded windows. The Windows source is in src/termios.c (called from src/SerialImp.c). -- Trent Jarvi tjarvi at qbang.org From m.j.tandy at warwick.ac.uk Wed Sep 9 03:27:10 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 10:27:10 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> I had a similar problem a while ago - hardware that would work with Hyperterminal but not with Rxtx. I don't know if this is a bug in RxTx or not - I tried to find where in the RxTx source code those functions are actually implemented - I got as far as the ioctl function in termios.c, where the TIOCMSET case sets the MSR byte in the termios struct, but I can't figure out where that gets written to the dcb struct's fDtrControl dword. It could be a bug, or it could just be me missing something. In any case, at the time I had this problem I wasn't equipped to debug RxTx so instead I created a special cable to satisfy the hardware's flow control while leaving the data connection straight through. Here's how I connected it: At the female end of the cable (i.e. the hardware I was connecting to) I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. I connected the ground and data pins straight through - that is, pin 5 female end to pin 5 male end, pin 2 female end to pin 2 male end, pin 3 female end to pin 3 male end. Anyway, using that cable bypassed the hardware's flow control, and got RxTx working just as well as HyperTerminal - although I slowed down my communication to make sure I didn't encounter a situation where the flow control would have come into effect, as I had bypassed it! Hope that helps. 2009/9/9 Nathaniel S. Parsons : > I added a call to setRTS() but nothing changed in Serial Port Monitor, no > matter what the argument was. Is this a bug, or did I call the wrong > function? > > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? > > -Nate > > On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > wrote: >> >> Thanks for the response. I'll try to get to the electronics store tomorrow >> to get more serial cables, even if it isn't the problem. >> >> I am using a different serial cable than I was in the spring. It's >> actually a Male/Female cable with a female-female adapter since the old >> cables aren't around anymore. The hardware's manual says nothing except to >> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >> should work in RXTX, right? >> >> Anyways, I've also noticed some things that are different between >> HyperTerminal, RXTX, and a separate program I found that communicates with >> the device (but doesn't do what I want, which is why I'm rolling my own >> program) >> >> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >> DTR indicators are green >> Other program - not sure what settings it thinks it's using, but only >> SPM's RTS indicator is green >> RXTX - no matter what flow control I set, only SPM's CTS and DTR >> indicators are on. >> >> From Serial Port Monitor's help files (paraphrased): the indicators >> display the state of the serial control lines >> >> RTS - Request To Send >> CTS - Clear To Send >> DTR - Data Terminal Ready >> >> Could this be related to the problem? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> wrote: >>> >>> OK, so: >>> >>> 1. It worked in spring but has stopped doing so and >>> 2. The data all arrives at once when you start hyperterminal. >>> >>> Is it possible you're using a different serial cable to connect to the >>> device, compared to the one you were using in spring? >>> >>> If so, the issue might be hardware flow control - that is, your device >>> might be buffering data because it can't transmit it until your >>> computer sets 'DTR' or 'RTS' or something like that. >>> >>> One way of bypassing hardware flow control is by using cables which >>> cross over certain wires so that the right signals are always being >>> sent; it's possible your old cable had these connections but your >>> current cable doesn't have them. If you can find the old cable, you >>> could put it back in and see if that fixes things? >>> >>> >>> 2009/9/8 Nathaniel S. Parsons : >>> > (Sorry if this is a double post, but I sent my original message without >>> > subscribing, and since this is an urgent problem, I thought I'd resend >>> > after >>> > subscribing to bypass the moderator limbo zone) >>> > >>> > Hi all, >>> > >>> > I've asked my question on StackOverflow already, so rather than >>> > copy-paste >>> > the question here, I'd like to redirect you there. >>> > >>> > Short version, I am no longer able to receive anything over RS-232 with >>> > RXTX, but other programs work fine. I'm definitely sending things, >>> > because >>> > when I connect with a different program, all the responses to the >>> > commands I >>> > sent via RXTX arrive all at once. >>> > >>> > Everything was fine in the spring, so what could have happened? Windows >>> > update? >>> > >>> > -Nate >>> > >>> > _______________________________________________ >>> > Rxtx mailing list >>> > Rxtx at qbang.org >>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>> > >>> > >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Wed Sep 9 03:54:45 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 12:54:45 +0300 Subject: [Rxtx] Xcode 3.x project available in CVS Message-ID: Hi everyone, I've just committed Apple Xcode 3.x (preferably 3.2) compatible project to CVS. The project can be used to develop and build Mac OS X 10.5+ compatible Universal Binary JNI library and RXTXcomm.jar. It's does not have dependencies to existing Autotools based build scripts - only standard Xcode installation is required. The older Xcode 2.x project is still there, but please note that it's not compatible with newer Xcode versions due to its dependency to deprecated Jam build system. The new project is available in rxtx-devel/MACOSX_IDE/Xcode3 How to get the source code from CVS: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Latest Xcode can be downloaded from Apple: http://developer.apple.com/technology/xcode.html -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 05:07:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 14:07:05 +0300 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: Nathaniel, I agree with Michael that your issue is probably with incorrect hardware flow control (RTS/CTS + possibly DTR/DSR). With RXTX you can do things manually, automatically or by mixing both ways. RXTX is "low-level" enough to let developer make those decisions. Which is proper. Automatic hardware flow-control: If you want to do automatic RTS/CTS flow control in both directions (from and to PC) you must set: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Note that you must combine flow control flags with bitwise OR ( ' | ' ) Manual: If you want to bypass all flow controls signals, or handle them manually you must set: setFlowControlMode( SerialPort.FLOWCONTROL_NONE ); In manual mode, you must manually handle controlling signals from PC and reading flow control signals from by the device: RTS - Request To Send -- setRTS() method can used to set this CTS - Clear To Send -- isCTS() method can be used to read this For example, it is entirely possible to manually implement normal RTS/ CTS flow control with RXTX without relying on low-level automatic implementation. Mixed: You can also configure serial port to handle RTS/CTS automatically in only one direction, then you must set one of: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN ); or setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_OUT ); Then you can either ignore or implement manually the flow control scheme in the other direction. DTR and DSR: These are not officially flow control signals, but might affect external devices (disable, standby etc.). Use and meaning of these depends on the device. DTR - Data Terminal Ready -- setDTR() method DSR - Data Set Ready -- setDSR() method CTS/RTS standards: Please note that there are two standard ways RTS/CTS flow control is done (depends on the device): asymmetric (RS-232) symmetric (RS-232-E / TIA-232-E) For more info see: http://en.wikipedia.org/wiki/RS232#RTS.2FCTS_handshaking Some devices may even use RTS/CTS to some other non-standard purpose. With those devices, enabling automatic RTS/CTS could cause very strange behaviour as they clearly require manual control of CTS/RTS. ---- As far as I know, RXTX properly controls all these signals all the way to actual RS232 pins - unless there is a new platform incompatibility bug that I'm not aware of;) Mostly it's just wrong combination and/or usage of these additional signals that cause problems receiving or sending. And the only solution is to really *know* how your device wants these signals handled - and then code your RXTX application accordingly. Creating non-standard cable is not the right solution in my opinion. Unfortunately some applications (like HyperTerminal for example) might hit more or less accidentally to the right combination of RTS/CTS/DTR/ DSR usage and make RXTX look bad in comparison. While all RXTX does by default is - well - nothing. It gives full control the developer. -- I > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port >> Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I >> found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't >> look wrong >> to me. Am I looking at the right function or is the problem >> somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > > >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store >>> tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since >>> the old >>> cables aren't around anymore. The hardware's manual says nothing >>> except to >>> use a "Straight cable" but I figured that if it worked in >>> HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that >>> communicates with >>> the device (but doesn't do what I want, which is why I'm rolling >>> my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's >>> RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but >>> only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> > >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect >>>> to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your >>>> device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>>> (Sorry if this is a double post, but I sent my original message >>>>> without >>>>> subscribing, and since this is an urgent problem, I thought I'd >>>>> resend >>>>> after >>>>> subscribing to bypass the moderator limbo zone) >>>>> >>>>> Hi all, >>>>> >>>>> I've asked my question on StackOverflow already, so rather than >>>>> copy-paste >>>>> the question here, I'd like to redirect you there. >>>>> >>>>> Short version, I am no longer able to receive anything over >>>>> RS-232 with >>>>> RXTX, but other programs work fine. I'm definitely sending things, >>>>> because >>>>> when I connect with a different program, all the responses to the >>>>> commands I >>>>> sent via RXTX arrive all at once. >>>>> >>>>> Everything was fine in the spring, so what could have happened? >>>>> Windows >>>>> update? >>>>> >>>>> -Nate >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 06:11:11 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 15:11:11 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings Message-ID: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Hi, Summary: Patch includes multiple minor code quality improvements and also fixes one possible null pointer segfault on Mac. After this patch, compilation on Mac OS X is error/warning free even with gcc -Wall setting. I'll submit more code quality patches later that focus more on linux/ win/java. Fixes: Code quality: - First level parentheses around assignment used as while-loop truth value - Some printf formats not a string literals and including no format arguments Invalid null pointer usage: - Mac: IOMasterPort was called with (int)NULL which does not always resolve to segfault safe value. Corrected to use MACH_PORT_NULL instead. Patch: The patch is against CVS head (@2009/09/09). Attached patch file is in 'cvs diff -up' format. I'll commit this patch to the CVS later this week if there are no objections. Feel free to comment. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090909.patch Type: application/octet-stream Size: 1966 bytes Desc: not available URL: From m.j.tandy at warwick.ac.uk Wed Sep 9 06:57:55 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 13:57:55 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> OK, I just ran a test with my copy of RxTx and the following program: import gnu.io.*; public class SerialTest { public static void main(String[] args) { try { CommPortIdentifier portid = CommPortIdentifier.getPortIdentifier("COM9"); SerialPort serialPort = (SerialPort)portid.open("Serial port DTR/RTS test", 1000); serialPort.setSerialPortParams(4800, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.disableReceiveTimeout(); for (int i=0 ; i<60 ; i++) { serialPort.setDTR(true); serialPort.setRTS(true); Thread.sleep(1000); serialPort.setDTR(false); serialPort.setRTS(false); Thread.sleep(1000); } } catch (Exception e) { e.printStackTrace(); System.exit(1); } System.exit(0); } } I'm using a USB-serial converter (Prolific PL-2303) and I used a multimeter to check that my DTR and RTS pins were both toggling, and they were - between +7 and -6.4 volts. In other words, on the computer I'm using at the moment, with the version of RxTx I'm using at the moment, setDTR and setRTS both seem to work fine. I don't know if it's worth it for you to perform the same test. I gather there are several different configurations for hardware flow control, (DTR/DSR handshaking as well as RTS/CTS handshaking, handshaking for half-duplex operation, and similar) so the cable that worked for me might still be worth a try. 2009/9/9 Michael Tandy : > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong >> to me. Am I looking at the right function or is the problem somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since the old >>> cables aren't around anymore. The hardware's manual says nothing except to >>> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that communicates with >>> the device (but doesn't do what I want, which is why I'm rolling my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>> > (Sorry if this is a double post, but I sent my original message without >>>> > subscribing, and since this is an urgent problem, I thought I'd resend >>>> > after >>>> > subscribing to bypass the moderator limbo zone) >>>> > >>>> > Hi all, >>>> > >>>> > I've asked my question on StackOverflow already, so rather than >>>> > copy-paste >>>> > the question here, I'd like to redirect you there. >>>> > >>>> > Short version, I am no longer able to receive anything over RS-232 with >>>> > RXTX, but other programs work fine. I'm definitely sending things, >>>> > because >>>> > when I connect with a different program, all the responses to the >>>> > commands I >>>> > sent via RXTX arrive all at once. >>>> > >>>> > Everything was fine in the spring, so what could have happened? Windows >>>> > update? >>>> > >>>> > -Nate >>>> > >>>> > _______________________________________________ >>>> > Rxtx mailing list >>>> > Rxtx at qbang.org >>>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>>> > >>>> > >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > From david at attglobal.net Wed Sep 9 09:17:27 2009 From: david at attglobal.net (David Schmidt) Date: Wed, 09 Sep 2009 11:17:27 -0400 Subject: [Rxtx] 2.2 Release plans Message-ID: <4AA7C707.5060802@attglobal.net> I'm holding off releasing an update to my project (adtpro.sourceforge.net) to support OSX Snow Leopard because I'd like to ship an "official" build of rxtx 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for toggling a port off). CVS is looking great on OSX - thanks to all who have been hard at work on that. I wish there were just one more update - Pre3? :-) My question... If I wanted to make a release in, say, a week... would it pay to wait for rxtx, or should I plan to build and ship a local build of 2.2 out of CVS myself? - David Schmidt From tjarvi at qbang.org Wed Sep 9 19:14:29 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:14:29 -0600 (MDT) Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: On Wed, 9 Sep 2009, Ilkka Myller wrote: > Hi, > > Summary: > > Patch includes multiple minor code quality improvements and also fixes one > possible null pointer segfault on Mac. > After this patch, compilation on Mac OS X is error/warning free even with gcc > -Wall setting. > I'll submit more code quality patches later that focus more on > linux/win/java. > > Fixes: > > Code quality: > - First level parentheses around assignment used as while-loop truth value > - Some printf formats not a string literals and including no format arguments > > Invalid null pointer usage: > - Mac: IOMasterPort was called with (int)NULL which does not always resolve > to segfault safe value. Corrected to use MACH_PORT_NULL instead. > > Patch: > > The patch is against CVS head (@2009/09/09). > Attached patch file is in 'cvs diff -up' format. > > I'll commit this patch to the CVS later this week if there are no objections. > Feel free to comment. > These ifdefs can go. If you like I can remove them when you are done. #ifdef DEBUG_MW mexErrMsgTxt( msg ); #else They are just printf like debug messages for use in an environment in which I could not get directly to stderr/stdout. I don't think anyone uses them anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Sep 9 19:17:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:17:43 -0600 (MDT) Subject: [Rxtx] 2.2 Release plans In-Reply-To: <4AA7C707.5060802@attglobal.net> References: <4AA7C707.5060802@attglobal.net> Message-ID: On Wed, 9 Sep 2009, David Schmidt wrote: > I'm holding off releasing an update to my project (adtpro.sourceforge.net) to > support OSX Snow Leopard because I'd like to ship an "official" build of rxtx > 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for > toggling a port off). CVS is looking great on OSX - thanks to all who have > been hard at work on that. I wish there were just one more update - Pre3? > :-) > > My question... If I wanted to make a release in, say, a week... would it pay > to wait for rxtx, or should I plan to build and ship a local build of 2.2 out > of CVS myself? > Hi David, I would suggest planning on shipping a local build in a 1 week timeframe. We could put another prerelease up but there are still fixes coming in. -- Trent Jarvi tjarvi at qbang.org From ilkka at myller.com Wed Sep 9 23:07:34 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:07:34 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: <04A41559-598C-4B6E-821A-DA90CB6228E7@myller.com> Patch (im-20090909.patch) has been committed to the CVS. Trent: I'll include DEBUG_MW cleanup to my next patch. > > On Wed, 9 Sep 2009, Ilkka Myller wrote: > >> Hi, >> >> Summary: >> >> Patch includes multiple minor code quality improvements and also >> fixes one possible null pointer segfault on Mac. >> After this patch, compilation on Mac OS X is error/warning free >> even with gcc -Wall setting. >> I'll submit more code quality patches later that focus more on >> linux/win/java. >> >> Fixes: >> >> Code quality: >> - First level parentheses around assignment used as while-loop >> truth value >> - Some printf formats not a string literals and including no format >> arguments >> >> Invalid null pointer usage: >> - Mac: IOMasterPort was called with (int)NULL which does not always >> resolve to segfault safe value. Corrected to use MACH_PORT_NULL >> instead. >> >> Patch: >> >> The patch is against CVS head (@2009/09/09). >> Attached patch file is in 'cvs diff -up' format. >> >> I'll commit this patch to the CVS later this week if there are no >> objections. >> Feel free to comment. >> > > These ifdefs can go. If you like I can remove them when you are done. > > #ifdef DEBUG_MW > mexErrMsgTxt( msg ); > #else > > They are just printf like debug messages for use in an environment > in which I could not get directly to stderr/stdout. I don't think > anyone uses them anymore. > > -- > Trent Jarvi > tjarvi at qbang.org From ilkka at myller.com Wed Sep 9 23:35:13 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:35:13 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= Message-ID: Hi, Summary: Patch fixes compiling on Linux distributions/kernels that dont ship with linux/utsrelease.h header and therefore have no UTS_RELEASE defined. Usually this applies only to newer distributions and/or kernels - for example Ubuntu 9.04. Fixes: The UTS_RELEASE vs uname checking in initialization functions is now done only in debug build and only when UTS_RELEASE is actually defined. Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910.patch Type: application/octet-stream Size: 9542 bytes Desc: not available URL: From ilkka at myller.com Thu Sep 10 06:43:02 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 15:43:02 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= In-Reply-To: References: Message-ID: Patch has been committed to CVS. > Hi, > > Summary: > > Patch fixes compiling on Linux distributions/kernels that dont ship > with linux/utsrelease.h header and therefore have no UTS_RELEASE > defined. > Usually this applies only to newer distributions and/or kernels - > for example Ubuntu 9.04. > > Fixes: > > The UTS_RELEASE vs uname checking in initialization functions is now > done only in debug build and only when UTS_RELEASE is actually > defined. > > Patch: > > The patch is against CVS head (@2009/09/10). > Attached patch file is in 'cvs diff -up' format. > > > Thanks, > > -- > I > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Thu Sep 10 09:08:01 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 18:08:01 +0300 Subject: [Rxtx] [Patch] Remove unused MathWorks MATLAB DEBUG_MW ifdefs Message-ID: <6DB57DB1-A47E-4435-9CD6-212B671A2849@myller.com> Summary: Patch removes unused MathWorks MATLAB timing debug ifdefs (DEBUG_MW). This is a request from Trent. Fixes: - Removes DEBUG_MW definitions - Removes unused mex....() function definitions - Corrects DEBUG_TIMING to work properly without mexPrintf (with Mac OS X specific format string fixes included) - Removes unused/duplicate timeval struct and DEBUG_TIMING definitions from SerialImp.c and SerialImp.h - Corrects fprintf call in SerialImp.cpp Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910b.patch Type: application/octet-stream Size: 9841 bytes Desc: not available URL: From Kapil_Gupta at hcl.in Thu Sep 10 10:25:29 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 10 Sep 2009 21:55:29 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, I am getting some problem with RXTX on macintosh (reading some data from the device attached to the usb port through usb to serial mechanism). I used the RXTX 2.1.7 then I got PortInUseException but after using 2.2pre it worked fine. But it works only for the first time, it hangs in the second time while opening the port. Please find the attached code. This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Thu Sep 10 13:00:14 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 22:00:14 +0300 Subject: [Rxtx] [Patch] Implement return value checking to file I/O calls Message-ID: Summary: The return value of some functions should always be used. For example, it is dangerous to not check the return value of a write(), read(), open(), fscanf() calls. This patch fixes such occurences in RXTX code. For example: unchecked read() call could result in later - and often seemingly unrelated - segfault due to undefined read buffer contents. After this patch the Linux build process is error/warning free even with gcc -Wall -Werror. Fixes: - Implemented return value checking to file I/O calls in SerialImp.c:fhs_lock(), uucp_lock() and is_device_locked() functions. - Added error recovery for fuserImp.c fscanf() calls. Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910c.patch Type: application/octet-stream Size: 3370 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Thu Sep 10 13:08:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 22:08:05 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> Hi Kapil, I believe this issue has been fixed in CVS version, but still exists in 2.2pre2 available from RXTX wiki. For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html As you've seen from the recent patches announced on this list, we are working very hard to make a new 2.2pre(?) release available. Meanwhile, you can compile your own RXTX binaries from CVS source. On Mac it should be exceptionally easy with new Xcode 3.x project files. Thank you for your patience, -- I > > I am getting some problem with RXTX on macintosh (reading some data > from the device attached to the usb port through usb to serial > mechanism). I used the RXTX 2.1.7 then I got PortInUseException but > after using 2.2pre it worked fine. But it works only for the first > time, it hangs in the second time while opening the port. From ilkka at myller.com Fri Sep 11 04:07:22 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 13:07:22 +0300 Subject: [Rxtx] [Patch] Windows build improvements (MinGW32, MSVC and LCC) Message-ID: <81D06766-8D51-485A-B2A2-624C8EA690BA@myller.com> Summary: Fixes various compiler warnings with Windows builds. Removes unused code blocks from compilation. After this patch the Windows build process is error/warning free with MinGW32, MSVC and LCC compilers - even with -Wall enabled. Does not fix: Latest LCC compiler version still fails even after this patch due to compiler trap error. Trap error does not specify source code location - it fails outputting SerialImp.obj binary. Compiling SerialImp.c without binary output works. Could this be a bug in LCC? Tested with clean RXTX source, latest standard LCC installation and with both Windows Vista SP1 x86 and Windows XP SP3 x86. Patch: The patch is against CVS (@2009/09/11). Attached patch file is in 'cvs diff -up' format. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090911.patch Type: application/octet-stream Size: 6673 bytes Desc: not available URL: From Kapil_Gupta at hcl.in Fri Sep 11 08:21:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Fri, 11 Sep 2009 19:51:24 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Ilkka, I tried getting the source code from the CVS but we could not able to do so, the CVS was not responding. Then we downloaded the 2.2 pre2 code and made the changes that are described in http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html but the problem didn't change. First time the device responds well and the second time it hangs. Did you see the code that we have sent to you, so that you can suggest if we are doing something wrong in our code. Again attaching if you have deleted that. Please suggest (does the CVS code can help rather using the patch provided by you?). Thanks, Kapil -----Original Message----- From: Ilkka Myller [mailto:ilkka at myller.com] Sent: Friday, September 11, 2009 12:38 AM To: Kapil Gupta Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Hi Kapil, I believe this issue has been fixed in CVS version, but still exists in 2.2pre2 available from RXTX wiki. For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html As you've seen from the recent patches announced on this list, we are working very hard to make a new 2.2pre(?) release available. Meanwhile, you can compile your own RXTX binaries from CVS source. On Mac it should be exceptionally easy with new Xcode 3.x project files. Thank you for your patience, -- I > > I am getting some problem with RXTX on macintosh (reading some data > from the device attached to the usb port through usb to serial > mechanism). I used the RXTX 2.1.7 then I got PortInUseException but > after using 2.2pre it worked fine. But it works only for the first > time, it hangs in the second time while opening the port. DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Fri Sep 11 09:33:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 18:33:33 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Hi Kapil, For CVS: Instructions at the old rxtx website are incorrect. Trent updated them, but to a wrong server address "qgang.org" -- the correct server is "qbang.org". Please follow instructions from rxtx wiki: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code About testing your code: When I have time (maybe this weekend), I'll test your code using Mac OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. What USB serial port you are using with your Mac? Something with FTDI chip? or maybe Prolific? What adapter driver version you are using? Just asking, so I can test with the same configuration. Meanwhile I suggest you: - Make sure you have the latest USB Serial adapter drivers, so we can eliminate past issues with those. - Check that you are not having multiple copies of librxtxSerial.jnilib (possibly different versions) in your java library path (=trouble;) - Check for any USB Serial adaptors kernel extension error messages in system log after testing your software (use Console.app to browse logs) -- I Kapil Gupta kirjoitti 11.9.2009 kello 17.21: > Hi Ilkka, > > I tried getting the source code from the CVS but we could not able > to do so, the CVS was not responding. Then we downloaded the 2.2 > pre2 code and made the changes that are described in http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html > but the problem didn't change. First time the device responds well > and the second time it hangs. > > Did you see the code that we have sent to you, so that you can > suggest if we are doing something wrong in our code. Again attaching > if you have deleted that. Please suggest (does the CVS code can help > rather using the patch provided by you?). > > Thanks, > Kapil > > -----Original Message----- > From: Ilkka Myller [mailto:ilkka at myller.com] > Sent: Friday, September 11, 2009 12:38 AM > To: Kapil Gupta > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second > time port open > > Hi Kapil, > > I believe this issue has been fixed in CVS version, but still exists > in 2.2pre2 available from RXTX wiki. > > For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html > > As you've seen from the recent patches announced on this list, we are > working very hard to make a new 2.2pre(?) release available. > > Meanwhile, you can compile your own RXTX binaries from CVS source. On > Mac it should be exceptionally easy with new Xcode 3.x project files. > > > Thank you for your patience, > > > -- > I > > >> >> I am getting some problem with RXTX on macintosh (reading some data >> from the device attached to the usb port through usb to serial >> mechanism). I used the RXTX 2.1.7 then I got PortInUseException but >> after using 2.2pre it worked fine. But it works only for the first >> time, it hangs in the second time while opening the port. > > > DISCLAIMER: > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential > and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of this > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > ----------------------------------------------------------------------------------------------------------------------- > From ilkka at myller.com Fri Sep 11 11:51:13 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 20:51:13 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Message-ID: <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> Ok, I debugged your code on Mac using USB-RS232 adapter + loopback adapter. My findings: there are no issues with RXTX in your code -- there are issues with threading and synchronization. Primary issue: you essentially lock the JVM main thread to 100% CPU usage with infinite loop: while (!processCompleted) { ; } Now.. I'm going to give you a bad advice, mostly because you have bigger threading issues there.. but we must continue somehow: A quick remedy to previous is: while (!processCompleted) { Thread.yield(); } Thread yielding gives other threads atleast a chance to run (and to processCompleted boolean to actually update in main thread context). What happens next is that your main-thread is allowed to continue and proceeds to closeConnection() call it otherwise would never reach. After that, connection closes properly.. main() method continues to "System.out.println(result);" and proceeds to exit JVM.. .. except.. Secondary issue: Exit is one thing JVM cant do since you have left a Timer thread hanging without proper closing in getData() method. Cancel it (uncomment that line) - and your code completes main() to a clean JVM exit. So, my advice to you is to focus on fixing threading, timers and synchronization. Design those well and everything works. Multithreading, done well or not, will not usually confuse RXTX ... but your own code might not be so lucky. -- I > > When I have time (maybe this weekend), I'll test your code using Mac > OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. >> >> Did you see the code that we have sent to you, so that you can >> suggest if we are doing something wrong in our code. Again >> attaching if you have deleted that. Please suggest (does the CVS >> code can help rather using the patch provided by you?). -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 11 15:19:26 2009 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 11 Sep 2009 17:19:26 -0400 Subject: [Rxtx] Can't run my Netbeans/Java s/w on a MAC Message-ID: <4AAABEDE.7020508@howardz.com> An HTML attachment was scrubbed... URL: From ilkka at myller.com Fri Sep 11 15:41:10 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 12 Sep 2009 00:41:10 +0300 Subject: [Rxtx] Can't run my Netbeans/Java s/w on a MAC In-Reply-To: <4AAABEDE.7020508@howardz.com> References: <4AAABEDE.7020508@howardz.com> Message-ID: <35D4BD73-B8CC-4DEE-A846-8858C9C9EBC7@myller.com> Hi, The bug that causes the segfault (invalid memory access) has been fixed (in CVS): http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html Next prerelease is coming (soon I hope), but the the 2.2pre2 fails when reopening the serial port on Mac OS X. -- I > > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] Jar > version = RXTX-2.2pre1 > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] native > lib Version = RXTX-2.2pre2 > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] Invalid > memory access of location 0x12b5e3938 rip=0x12955012f > 9/6/09 3:46:00 PM ReportCrash[6164] Saved crash report for java > [6162] version 13.0.0 (13.0.0) to /Users/myles/Library/Logs/ > DiagnosticReports/java_2009-09-06-154600_myles-PowerBook-PP-108.crash -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Fri Sep 11 20:15:31 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 11 Sep 2009 20:15:31 -0600 (MDT) Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Message-ID: On Fri, 11 Sep 2009, Ilkka Myller wrote: > Hi Kapil, > > For CVS: > > Instructions at the old rxtx website are incorrect. Trent updated them, but > to a wrong server address "qgang.org" -- the correct server is "qbang.org". > Please follow instructions from rxtx wiki: > > http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code The old website has been corrected. -- Trent Jarvi tjarvi at qbang.org From dvd at newfoundmarket.com Sat Sep 12 11:49:48 2009 From: dvd at newfoundmarket.com (DVD) Date: Sat, 12 Sep 2009 13:49:48 -0400 Subject: [Rxtx] RXTX on linux hang Message-ID: <4AABDF3C.2040908@newfoundmarket.com> Hello: I just did a fresh install of RXTZ on both Ubuntu and centos, Java version 6, update 12 I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with the Usage example from your website Two way communcation with the serial port I used the computer's serial port /dev/ttyS0, with UART 16550A the program simply hang. The port was opened and both input/output streamed were opened but the writing/reading are not working. Any help would be appreciated. I tried this program on windows and it worked fine. Thanks From ilkka at myller.com Sat Sep 12 15:31:26 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sun, 13 Sep 2009 00:31:26 +0300 Subject: [Rxtx] RXTX on linux hang In-Reply-To: <4AABDF3C.2040908@newfoundmarket.com> References: <4AABDF3C.2040908@newfoundmarket.com> Message-ID: Hi, It's very hard to say what could be wrong without more details. Can you tell me more about your Linux setup: - Output of: uname -a - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your test code running) - Output of: cat /proc/tty/driver/serial - Are you you testing with root privileges - What kind of device you are communicating with (or just a loopback dongle)? - Does your device expect some specific flow control and/or specific state of DTR/DSR signals? - Have you tried configuring those flow controls and other RS232 signals in your test code? Did they work? - Do other simple terminal programs work (easiest to try: screen /dev/ ttyS0 )? - What is the CPU usage (use 'top' or some other process monitor your like) of your test software when it "hangs"? I can try to duplicate your issue on Ubuntu 9.04 (both x86 and x86_64), Centos 5 (x86) and Debian 5.0 (x86). I'd prefer to test with the same kind of system you have.. Thanks, -- I > > I just did a fresh install of RXTZ on both Ubuntu and centos, Java > version 6, update 12 > I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with > the Usage example from > your website > > Two way communcation with the serial port > > > I used the computer's serial port /dev/ttyS0, with UART 16550A > > the program simply hang. The port was opened and both input/output > streamed were opened > but the writing/reading are not working. > > Any help would be appreciated. I tried this program on windows and > it worked fine. From dvd at newfoundmarket.com Sat Sep 12 21:20:14 2009 From: dvd at newfoundmarket.com (DVD) Date: Sat, 12 Sep 2009 23:20:14 -0400 Subject: [Rxtx] RXTX on linux hang In-Reply-To: References: <4AABDF3C.2040908@newfoundmarket.com> Message-ID: <4AAC64EE.7050904@newfoundmarket.com> Thank you very much for the steps. It is pin out problem. Again, Thanks. Ilkka Myller wrote: > Hi, > > It's very hard to say what could be wrong without more details. > Can you tell me more about your Linux setup: > > - Output of: uname -a > - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your > test code running) > - Output of: cat /proc/tty/driver/serial > - Are you you testing with root privileges > - What kind of device you are communicating with (or just a loopback > dongle)? > - Does your device expect some specific flow control and/or specific > state of DTR/DSR signals? > - Have you tried configuring those flow controls and other RS232 > signals in your test code? Did they work? > - Do other simple terminal programs work (easiest to try: screen > /dev/ttyS0 )? > - What is the CPU usage (use 'top' or some other process monitor your > like) of your test software when it "hangs"? > > > I can try to duplicate your issue on Ubuntu 9.04 (both x86 and > x86_64), Centos 5 (x86) and Debian 5.0 (x86). > I'd prefer to test with the same kind of system you have.. > > > Thanks, > > -- > I > > >> >> I just did a fresh install of RXTZ on both Ubuntu and centos, Java >> version 6, update 12 >> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with >> the Usage example from >> your website >> >> Two way communcation with the serial port >> >> >> >> I used the computer's serial port /dev/ttyS0, with UART 16550A >> >> the program simply hang. The port was opened and both input/output >> streamed were opened >> but the writing/reading are not working. >> >> Any help would be appreciated. I tried this program on windows and >> it worked fine. > From tjarvi at qbang.org Sun Sep 13 12:06:33 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Sep 2009 12:06:33 -0600 (MDT) Subject: [Rxtx] RXTX on linux hang In-Reply-To: <4AAC64EE.7050904@newfoundmarket.com> References: <4AABDF3C.2040908@newfoundmarket.com> <4AAC64EE.7050904@newfoundmarket.com> Message-ID: Hi, Would it be possible to get a short paragraph from you describing the pinout problem and how you discovered it? We can add that to the wiki to help others get past the problem faster next time. On Sat, 12 Sep 2009, DVD wrote: > Thank you very much for the steps. It is pin out problem. > Again, Thanks. > > Ilkka Myller wrote: >> Hi, >> >> It's very hard to say what could be wrong without more details. >> Can you tell me more about your Linux setup: >> >> - Output of: uname -a >> - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your test >> code running) >> - Output of: cat /proc/tty/driver/serial >> - Are you you testing with root privileges >> - What kind of device you are communicating with (or just a loopback >> dongle)? >> - Does your device expect some specific flow control and/or specific state >> of DTR/DSR signals? >> - Have you tried configuring those flow controls and other RS232 signals in >> your test code? Did they work? >> - Do other simple terminal programs work (easiest to try: screen /dev/ttyS0 >> )? >> - What is the CPU usage (use 'top' or some other process monitor your like) >> of your test software when it "hangs"? >> >> >> I can try to duplicate your issue on Ubuntu 9.04 (both x86 and x86_64), >> Centos 5 (x86) and Debian 5.0 (x86). >> I'd prefer to test with the same kind of system you have.. >> >> >> Thanks, >> >> -- >> I >> >> >>> >>> I just did a fresh install of RXTZ on both Ubuntu and centos, Java version >>> 6, update 12 >>> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with the >>> Usage example from >>> your website >>> >>> Two way communcation with the serial port >>> >>> >>> I used the computer's serial port /dev/ttyS0, with UART 16550A >>> >>> the program simply hang. The port was opened and both input/output >>> streamed were opened >>> but the writing/reading are not working. >>> >>> Any help would be appreciated. I tried this program on windows and it >>> worked fine. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dvd at newfoundmarket.com Sun Sep 13 19:18:08 2009 From: dvd at newfoundmarket.com (DVD) Date: Sun, 13 Sep 2009 21:18:08 -0400 Subject: [Rxtx] RXTX on linux hang In-Reply-To: References: <4AABDF3C.2040908@newfoundmarket.com> <4AAC64EE.7050904@newfoundmarket.com> Message-ID: <4AAD99D0.3030206@newfoundmarket.com> Hello, It was a human mistake during wiring and was discovered after staring at it for a while :-). Nothing technical worth mentioning. Thanks Trent Jarvi wrote: > > Hi, > > Would it be possible to get a short paragraph from you describing the > pinout problem and how you discovered it? We can add that to the wiki > to help others get past the problem faster next time. > > On Sat, 12 Sep 2009, DVD wrote: > >> Thank you very much for the steps. It is pin out problem. >> Again, Thanks. >> >> Ilkka Myller wrote: >>> Hi, >>> >>> It's very hard to say what could be wrong without more details. >>> Can you tell me more about your Linux setup: >>> >>> - Output of: uname -a >>> - Output of: stty -a -F /dev/ttyS0 (if possible: with and without >>> your test code running) >>> - Output of: cat /proc/tty/driver/serial >>> - Are you you testing with root privileges >>> - What kind of device you are communicating with (or just a loopback >>> dongle)? >>> - Does your device expect some specific flow control and/or specific >>> state of DTR/DSR signals? >>> - Have you tried configuring those flow controls and other RS232 >>> signals in your test code? Did they work? >>> - Do other simple terminal programs work (easiest to try: screen >>> /dev/ttyS0 )? >>> - What is the CPU usage (use 'top' or some other process monitor >>> your like) of your test software when it "hangs"? >>> >>> >>> I can try to duplicate your issue on Ubuntu 9.04 (both x86 and >>> x86_64), Centos 5 (x86) and Debian 5.0 (x86). >>> I'd prefer to test with the same kind of system you have.. >>> >>> >>> Thanks, >>> >>> -- >>> I >>> >>> >>>> >>>> I just did a fresh install of RXTZ on both Ubuntu and centos, Java >>>> version 6, update 12 >>>> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with >>>> the Usage example from >>>> your website >>>> >>>> Two way communcation with the serial port >>>> >>>> >>>> I used the computer's serial port /dev/ttyS0, with UART 16550A >>>> >>>> the program simply hang. The port was opened and both input/output >>>> streamed were opened >>>> but the writing/reading are not working. >>>> >>>> Any help would be appreciated. I tried this program on windows and >>>> it worked fine. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From Kapil_Gupta at hcl.in Mon Sep 14 08:37:23 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Mon, 14 Sep 2009 20:07:23 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B30A4F25D@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Ilkka, We have done that also, but no success. I am attaching the code, please check the updated code also. We are not using any FTDI/Prolific chip set. We are using TI chip set. We are having only one copy of JNI lib. No Error in console for kernel driver. Warm Regards, Kapil From: Ilkka Myller [mailto:ilkka at myller.com] Sent: Friday, September 11, 2009 11:21 PM To: Kapil Gupta Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Ok, I debugged your code on Mac using USB-RS232 adapter + loopback adapter. My findings: there are no issues with RXTX in your code -- there are issues with threading and synchronization. Primary issue: you essentially lock the JVM main thread to 100% CPU usage with infinite loop: while (!processCompleted) { ; } Now.. I'm going to give you a bad advice, mostly because you have bigger threading issues there.. but we must continue somehow: A quick remedy to previous is: while (!processCompleted) { Thread.yield(); } Thread yielding gives other threads atleast a chance to run (and to processCompleted boolean to actually update in main thread context). What happens next is that your main-thread is allowed to continue and proceeds to closeConnection() call it otherwise would never reach. After that, connection closes properly.. main() method continues to "System.out.println(result);" and proceeds to exit JVM.. .. except.. Secondary issue: Exit is one thing JVM cant do since you have left a Timer thread hanging without proper closing in getData() method. Cancel it (uncomment that line) - and your code completes main() to a clean JVM exit. So, my advice to you is to focus on fixing threading, timers and synchronization. Design those well and everything works. Multithreading, done well or not, will not usually confuse RXTX ... but your own code might not be so lucky. -- I When I have time (maybe this weekend), I'll test your code using Mac OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. Did you see the code that we have sent to you, so that you can suggest if we are doing something wrong in our code. Again attaching if you have deleted that. Please suggest (does the CVS code can help rather using the patch provided by you?). DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10005 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Mon Sep 14 17:03:55 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 15 Sep 2009 02:03:55 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B30A4F25D@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B30A4F25D@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <989B2FAA-5E5A-4F47-AF23-04CE1A6A20F7@myller.com> Kapil, You did not fix the primary issue. Your while() loop still blocks the main thread and the code is not working for the same reasons I stated before. .. but .. I created a demonstration code, which does not try to duplicate the behaviour of your code, but instead demonstrates few concepts: 1. Safe opening of the serial port with full error checking 2. Proper handling of text encoding using Reader/Writer. If your protocol handles plaintext, I recommend you use encoding capable streams. 3. Asynchronous multi-threaded receiving and transmitting (separate thread for each, with their own packet (=string, in this case) queues) 4. Handling serial port data-available events without blocking the event handler (=event only signals async. receiver) 5. Controlling access to serial port in multithreaded app using ReentrantLock (still allows embedded transmit->receive, as demonstrated) 6. Signaling thread from other thread with wait() -> notify() (demonstrated in serial event handling) The code does one simple thing: sends a US-ASCII encoded string to serial port with CR+LF and expects the same line to be received back. I used simple loopback adapter hardware to test this. Normally, doing just this simple task does not require such heavy multi-threading async. receiver/transmitter structures, but I created them to demonstrate various multi-threading concepts, and how they can be used with RXTX. The code is not perfect, it's still a quick hack to demonstrate few things. For example, it lacks proper error handling and propagation in async. receiver/transmitter. However, this code is "profiler clean". It's threads are mostly idle waiting other threads or actual events from RXTX. No thread is blocked in high CPU-% loops etc. when receiving or sending. This also scales nicely to run on multiple CPU's with modern JVM's. When implementing commercial protocol handlers this is how things should always be. Doing "while(someBoolean) {}" is generally not the correct method to sync things. -- I > Hi Ilkka, > > We have done that also, but no success. I am attaching the code, > please check the updated code also. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 11656 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail4ng at gmail.com Tue Sep 15 03:02:48 2009 From: mail4ng at gmail.com (Daniel Weinand) Date: Tue, 15 Sep 2009 11:02:48 +0200 Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby Message-ID: <4AAF5838.7080707@gmail.com> Hello, i'm using RXTX with a USB to Serial Adapter on Linux and Windows machines. Everything works great. but now i have a problem on a Vista machine with standby mode. after the machine wakes up i'll get an infinite error loop: Error 0x5 at ..\src\termios.c(2712): Access Denied Error 0x5 at ..\src\termios.c(517): Access Denied ... and so on. My Application runs as a windows service and so it tries to enumerate and connect to the port directly after it wakes up. but the Port is blocked until i restart the whole machine and everything starts from 0. i'm using rxtx 2.2pre2 is this a known problem and how to solve this? From stefan.frings at vodafone.com Tue Sep 15 09:08:04 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Tue, 15 Sep 2009 17:08:04 +0200 Subject: [Rxtx] Reloading C library after USB error Message-ID: Hello, I wrote a web application that uses rxtxcomm to communicate to USB devices through virtual serial ports (e.g. /dev/ttyUSB0) on Linux. When I unplug a device while the port is open and then plug it back, I cannot access it anymore. I need to kill -9 Tomcat and then restart it. I think that I need to re-load the C library. Another problem occurs when I plug in an USB device after my web application has started. In this case, the new device cannot be accessed through rxtxcomm. Again, I assume that I need to relaod the C library. I am not able to shut-down my web application after these two errors occur. Tomcat reports, that the shut-down failed. How can I reload the C library without hardly killing my running Tomcat? -------------- next part -------------- An HTML attachment was scrubbed... URL: From petter.real at gmail.com Tue Sep 15 14:32:29 2009 From: petter.real at gmail.com (Petter Rafael Villa Real) Date: Tue, 15 Sep 2009 17:32:29 -0300 Subject: [Rxtx] RXTX on Ubuntu 9.04 with lock in /var/lock/LCK..ttyS0. Message-ID: Hi, I always used the RXTX to read/write the serial successfully on Windows. But now I need to use Linux Ubuntu 9.04, I changed to COM1, with on Windows, to /dev/ttyS0, the reading starts on the terminal but the RXTX will warn that you must release the lock of the serial. In the RXTX documentation is indicated add uucd User groups and / or lock to resolve this problem, but in Ubuntu do not have this group. Does anyone have experience with Ubuntu to help me? P.S.: sorry for my bad english. Thank you. -- -- --------------------------------------------------------------------- Petter R. Villa Real Silva -- Desenvolvedor Web Viamais Desenvolvimento Web Powered by Java/Oracle PHP/MySQL Web Alocation e Hosting - PHP/JSP --------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at attglobal.net Tue Sep 15 19:36:38 2009 From: david at attglobal.net (David Schmidt) Date: Tue, 15 Sep 2009 21:36:38 -0400 Subject: [Rxtx] 2.2 Release plans In-Reply-To: References: <4AA7C707.5060802@attglobal.net> Message-ID: <4AB04126.5070002@attglobal.net> Trent Jarvi wrote: > On Wed, 9 Sep 2009, David Schmidt wrote: > >> I'm holding off releasing an update to my project >> (adtpro.sourceforge.net) to support OSX Snow Leopard because I'd like >> to ship an "official" build of rxtx 2.2. (I wouldn't mind shipping >> 2.2Pre2, but it lacks a critical fix for toggling a port off). CVS is >> looking great on OSX - thanks to all who have been hard at work on >> that. I wish there were just one more update - Pre3? :-) >> >> My question... If I wanted to make a release in, say, a week... would >> it pay to wait for rxtx, or should I plan to build and ship a local >> build of 2.2 out of CVS myself? >> > > Hi David, > > I would suggest planning on shipping a local build in a 1 week > timeframe. We could put another prerelease up but there are still fixes > coming in. Thanks for the encouragement, guys. I'm having a little less luck now - building for OSX on an Intel box runs on a PPC box, but not on Intel... weird. I guess I'll wait a bit more. :-) - David From david at attglobal.net Tue Sep 15 19:51:28 2009 From: david at attglobal.net (David Schmidt) Date: Tue, 15 Sep 2009 21:51:28 -0400 Subject: [Rxtx] FTDI chipset speed - much slower? Message-ID: <4AB044A0.10509@attglobal.net> I am finding that my app is behaving really slowly when I'm connecting with a FTDI chipset equipped USB-serial adapter. I'm finding my app to be "fast" when I use native UART ports, Prolific or Keyspan USB adapters. But my FTDI adapters are remarkably, astonishingly slower when sending data (in my case, this means moving data from the DE-9 to the USB end) than any other method. I mean it is maybe 1/5 the "normal" speed I see from every other method. CPU remains calm on the USB (i.e. Mac or PC) end of the adapter. It's just really slow. Data moving in the other direction seems to run at full speed. I'm suspecting I'm doing something wrong along the way that is reacting badly with this chipset. My initial, lazy question, before exposing my code to the harsh light of day: is there anything obvious I might be doing wrong to this chipset to make it run so slowly? Has anyone else run into the same problem? - David From tjarvi at qbang.org Tue Sep 15 20:03:51 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 15 Sep 2009 20:03:51 -0600 (MDT) Subject: [Rxtx] FTDI chipset speed - much slower? In-Reply-To: <4AB044A0.10509@attglobal.net> References: <4AB044A0.10509@attglobal.net> Message-ID: On Tue, 15 Sep 2009, David Schmidt wrote: > I am finding that my app is behaving really slowly when I'm connecting > with a FTDI chipset equipped USB-serial adapter. I'm finding my app to be > "fast" when I use native UART ports, Prolific or Keyspan USB adapters. > But my FTDI adapters are remarkably, astonishingly slower when sending > data (in my case, this means moving data from the DE-9 to the USB end) > than any other method. I mean it is maybe 1/5 the "normal" speed I see > from every other method. CPU remains calm on the USB (i.e. Mac or PC) end > of the adapter. It's just really slow. Data moving in the other > direction seems to run at full speed. > > I'm suspecting I'm doing something wrong along the way that is reacting > badly with this chipset. My initial, lazy question, before exposing my > code to the harsh light of day: is there anything obvious I might be doing > wrong to this chipset to make it run so slowly? Has anyone else run into > the same problem? > Given that rxtx does not treat usb special, it may be something to do with the nature of USB serial dongles. One suspicion I've had is that the event loop is competing for bandwidth by trying to check the UART status which is on the other side of the USB line. 1/5th is fairly significant. This is just writing/reading? How large are the transfers? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 15 20:07:12 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 15 Sep 2009 20:07:12 -0600 (MDT) Subject: [Rxtx] Reloading C library after USB error In-Reply-To: References: Message-ID: On Tue, 15 Sep 2009, Frings, Stefan, VF-DE wrote: > Hello, > ? > I wrote a web application that uses rxtxcomm to communicate to USB > devices through virtual serial ports (e.g. /dev/ttyUSB0) on Linux. > ? > When I unplug a device while the port is open and then plug it back, I > cannot access it anymore. I need to kill -9 Tomcat and then restart it. I > think that?I need to re-load the C library. > ? > Another problem occurs when I plug in an USB device after my web > application has started. In this case, the new device cannot be accessed > through rxtxcomm. Again, I assume that I need to relaod the C library. > ? > I am not able to shut-down my web application after these two errors > occur.? Tomcat reports, that the shut-down failed. > ? > How can I reload the C library without hardly killing my running Tomcat? > > I don't think the native library needs to shut down but the code does not expect the file descriptor to go invalid. Duct taping the USB dongle isnt always an option but thats how rxtx is currently coded. read/write and the event loop could all fail at any time and need to shut down the port. This code is not in place. We don't get USB events through the API so it has to be done by checking errors. The library also needs the ability to rescan the available ports. When it was written, you had to shut down the computer to remove a serial port so rescanning wasnt a concern. If those two fixes are made, you will be able to exit tomcat gracefully. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 15 20:08:54 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 15 Sep 2009 20:08:54 -0600 (MDT) Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby In-Reply-To: <4AAF5838.7080707@gmail.com> References: <4AAF5838.7080707@gmail.com> Message-ID: On Tue, 15 Sep 2009, Daniel Weinand wrote: > Hello, > > i'm using RXTX with a USB to Serial Adapter on Linux and Windows machines. > Everything works great. > but now i have a problem on a Vista machine with standby mode. after the > machine wakes up i'll get an infinite error loop: > > > Error 0x5 at ..\src\termios.c(2712): Access Denied > Error 0x5 at ..\src\termios.c(517): Access Denied > ... > > and so on. > > My Application runs as a windows service and so it tries to enumerate and > connect to the port directly > after it wakes up. but the Port is blocked until i restart the whole > machine and everything starts from 0. > > i'm using rxtx 2.2pre2 > > is this a known problem and how to solve this? It is a known problem. The kernel driver isnt restoring the fd. See the previous post for what is required prior to being able to handle it in your code. -- Trent Jarvi tjarvi at qbang.org From nsp25 at cornell.edu Tue Sep 15 20:50:11 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 15 Sep 2009 22:50:11 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> Message-ID: Thank you very much Ikka and Mike. Sorry I didn't get back sooner, but your emails got buried in my inbox, and I didn't see them until yesterday, or get to try it out until today. The following body of the connect method worked (same serial cable): SerialPort port = (SerialPort) CommPortIdentifier.getPortIdentifier("COM1").open("", 1000); port.setSerialPortParams(baud, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); // Never tried this before, it was just one or the other port.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT); port.setRTS(true); // Seems to work when flow control is set right port.setDTR(false); // Just in case port.disableReceiveTimeout(); However, I noticed what could be a bug in RXTX for Windows XP. While running PortMon, I discovered what could be problems in the (attached) log file, namely INVALID_PARAMETER return codes for IOCTL_SERIAL_CLR_RTS happens, I believe) and twice for IOCTL_SERIAL_SET_RTS. The log is nearly identical each time I connect, with the same failures. What's the easiest way I can run RXTX in debug mode? I have visual studio 2008, if that helps. If anyone wants to help me track this (new?) bug down, I can provide whatever computer information you ask for. -Nate On Wed, Sep 9, 2009 at 8:57 AM, Michael Tandy wrote: > OK, I just ran a test with my copy of RxTx and the following program: > > import gnu.io.*; > public class SerialTest { > public static void main(String[] args) { > > try { > CommPortIdentifier portid = > CommPortIdentifier.getPortIdentifier("COM9"); > SerialPort serialPort = (SerialPort)portid.open("Serial > port DTR/RTS test", 1000); > serialPort.setSerialPortParams(4800, > SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > serialPort.disableReceiveTimeout(); > for (int i=0 ; i<60 ; i++) { > serialPort.setDTR(true); > serialPort.setRTS(true); > Thread.sleep(1000); > serialPort.setDTR(false); > serialPort.setRTS(false); > Thread.sleep(1000); > } > } catch (Exception e) { > e.printStackTrace(); > System.exit(1); > } > System.exit(0); > } > } > > I'm using a USB-serial converter (Prolific PL-2303) and I used a > multimeter to check that my DTR and RTS pins were both toggling, and > they were - between +7 and -6.4 volts. > > In other words, on the computer I'm using at the moment, with the > version of RxTx I'm using at the moment, setDTR and setRTS both seem > to work fine. I don't know if it's worth it for you to perform the > same test. > > I gather there are several different configurations for hardware flow > control, (DTR/DSR handshaking as well as RTS/CTS handshaking, > handshaking for half-duplex operation, and similar) so the cable that > worked for me might still be worth a try. > > > 2009/9/9 Michael Tandy : > > I had a similar problem a while ago - hardware that would work with > > Hyperterminal but not with Rxtx. > > > > I don't know if this is a bug in RxTx or not - I tried to find where > > in the RxTx source code those functions are actually implemented - I > > got as far as the ioctl function in termios.c, where the TIOCMSET case > > sets the MSR byte in the termios struct, but I can't figure out where > > that gets written to the dcb struct's fDtrControl dword. It could be a > > bug, or it could just be me missing something. > > > > In any case, at the time I had this problem I wasn't equipped to debug > > RxTx so instead I created a special cable to satisfy the hardware's > > flow control while leaving the data connection straight through. > > Here's how I connected it: > > > > At the female end of the cable (i.e. the hardware I was connecting to) > > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > > I connected the ground and data pins straight through - that is, pin 5 > > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > > 3 female end to pin 3 male end. > > > > Anyway, using that cable bypassed the hardware's flow control, and got > > RxTx working just as well as HyperTerminal - although I slowed down my > > communication to make sure I didn't encounter a situation where the > > flow control would have come into effect, as I had bypassed it! > > > > Hope that helps. > > > > > > 2009/9/9 Nathaniel S. Parsons : > >> I added a call to setRTS() but nothing changed in Serial Port Monitor, > no > >> matter what the argument was. Is this a bug, or did I call the wrong > >> function? > >> > >> I tried to find the c code behind this function, and I think I found it > in > >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look > wrong > >> to me. Am I looking at the right function or is the problem somewhere > else? > >> > >> -Nate > >> > >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > > >> wrote: > >>> > >>> Thanks for the response. I'll try to get to the electronics store > tomorrow > >>> to get more serial cables, even if it isn't the problem. > >>> > >>> I am using a different serial cable than I was in the spring. It's > >>> actually a Male/Female cable with a female-female adapter since the old > >>> cables aren't around anymore. The hardware's manual says nothing except > to > >>> use a "Straight cable" but I figured that if it worked in > HyperTerminal, it > >>> should work in RXTX, right? > >>> > >>> Anyways, I've also noticed some things that are different between > >>> HyperTerminal, RXTX, and a separate program I found that communicates > with > >>> the device (but doesn't do what I want, which is why I'm rolling my own > >>> program) > >>> > >>> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS > and > >>> DTR indicators are green > >>> Other program - not sure what settings it thinks it's using, but only > >>> SPM's RTS indicator is green > >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR > >>> indicators are on. > >>> > >>> From Serial Port Monitor's help files (paraphrased): the indicators > >>> display the state of the serial control lines > >>> > >>> RTS - Request To Send > >>> CTS - Clear To Send > >>> DTR - Data Terminal Ready > >>> > >>> Could this be related to the problem? > >>> > >>> -Nate > >>> > >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy > > >>> wrote: > >>>> > >>>> OK, so: > >>>> > >>>> 1. It worked in spring but has stopped doing so and > >>>> 2. The data all arrives at once when you start hyperterminal. > >>>> > >>>> Is it possible you're using a different serial cable to connect to the > >>>> device, compared to the one you were using in spring? > >>>> > >>>> If so, the issue might be hardware flow control - that is, your device > >>>> might be buffering data because it can't transmit it until your > >>>> computer sets 'DTR' or 'RTS' or something like that. > >>>> > >>>> One way of bypassing hardware flow control is by using cables which > >>>> cross over certain wires so that the right signals are always being > >>>> sent; it's possible your old cable had these connections but your > >>>> current cable doesn't have them. If you can find the old cable, you > >>>> could put it back in and see if that fixes things? > >>>> > >>>> > >>>> 2009/9/8 Nathaniel S. Parsons : > >>>> > (Sorry if this is a double post, but I sent my original message > without > >>>> > subscribing, and since this is an urgent problem, I thought I'd > resend > >>>> > after > >>>> > subscribing to bypass the moderator limbo zone) > >>>> > > >>>> > Hi all, > >>>> > > >>>> > I've asked my question on StackOverflow already, so rather than > >>>> > copy-paste > >>>> > the question here, I'd like to redirect you there. > >>>> > > >>>> > Short version, I am no longer able to receive anything over RS-232 > with > >>>> > RXTX, but other programs work fine. I'm definitely sending things, > >>>> > because > >>>> > when I connect with a different program, all the responses to the > >>>> > commands I > >>>> > sent via RXTX arrive all at once. > >>>> > > >>>> > Everything was fine in the spring, so what could have happened? > Windows > >>>> > update? > >>>> > > >>>> > -Nate > >>>> > > >>>> > _______________________________________________ > >>>> > Rxtx mailing list > >>>> > Rxtx at qbang.org > >>>> > http://mailman.qbang.org/mailman/listinfo/rxtx > >>>> > > >>>> > > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at qbang.org > >>>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: connection_log.csv Type: application/octet-stream Size: 9725 bytes Desc: not available URL: From stefan.frings at vodafone.com Wed Sep 16 00:06:52 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Wed, 16 Sep 2009 08:06:52 +0200 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time Message-ID: Hello Daniel Weinand, your proble is surely related to my issue. Im not familiar with Mac OS, but I know that Linux and also Windows normally disconnect all USB devices during standby mode and reconnect them after power-on. RxTx seems to have a problem when a device disappears or appears while the C library is loaded. I think the C library should be changed to re-check the list of available ports whenever the Java application attempts to enumerate or open a port. And when a port disappears while it is open, the library should close it and throw an AlreadyClosedException. I think the Java application should be able to recover itself from temporarily lost devices, and it should also be able to open devices that have been plugged in AFTER the library was loaded. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.frings at vodafone.com Wed Sep 16 00:09:34 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Wed, 16 Sep 2009 08:09:34 +0200 Subject: [Rxtx] Reloading C library after USB error In-Reply-To: References: Message-ID: Hello Trent, Yes, I think the same. The library was obviously not written for USB devices. Is anybody aware of an alternative that works fine with USB / Hotpluggable devices? From stefan.frings at vodafone.com Wed Sep 16 00:12:58 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Wed, 16 Sep 2009 08:12:58 +0200 Subject: [Rxtx] RXTX on Ubuntu 9.04 with lock in /var/lock/LCK..ttyS0 Message-ID: Hello Petter, the serial ports are normally only writeable by root and by users that are in the dialout group. For your case, a solution might be, to add yourself to the dialout group in /etc/group. On my machines, RxTx wporks fine. I am using Ubuntu 8.10 and 9.04 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.frings at vodafone.com Wed Sep 16 00:17:27 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Wed, 16 Sep 2009 08:17:27 +0200 Subject: [Rxtx] FTDI chipset speed - much slower? Message-ID: Hello David, Im not 100% sure, but I highly assume that the delays are produces by the USB communication. USB transfers data in packets and there are large buffers of several hundreds characters, similar to ethernet. There is no real time communication. So when your software thinks that it has sent a character, this was not the case. It was only put into a buffer and will appears at the end of your USB2Serial cable after some time - I assume somewhat around 0,3ms. I noticed the same behavious with different USB2Serial adapters on Linux with plain C programs (not anything around Java and RxTx). -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 16 01:06:41 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 16 Sep 2009 10:06:41 +0300 Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby In-Reply-To: References: <4AAF5838.7080707@gmail.com> Message-ID: <0EB22ACB-0676-44DE-BBD3-A9D38CFD2E88@myller.com> Windows is not my primary platform, but I agree with Trent. I tested this too and noticed that ClearCommError() does not fail because RXTX loses fd (why would it), but because fd seems to no longer exist, or is reused, on kernel side. Resulting in access denied (5) error. Definitely something RXTX has no control of. Also the USB device re-registers itself, causing all it's previous file handles invalidated. After few seconds after waking from sleep, new ones can be created with CreateFile calls - as expected. FTDI chips can be reprogrammed not to do this reconnection cycle on USB sleep (with mprog 3.5 software). I dont know how well Windows follows that setting. Also Windows allows disabling USB power saving on specific USB devices. After those settings, it entirely up to the USB driver to do the right thing. .. which I'm not entirely sure it will - even if it's technically possible to retain fd's over sleep the driver might still be hardwired to reconnect the device on power save events. -- Basicly all these issues are about the fact that someone/something rips off the UART hardware RXTX is controlling. The serial comms features on most operating systems are not equipped to handle this since UART is expected to be integral part of the system. Well, USB has certainly changed that. Now not only the serial device can be unplugged (which is handled properly by protocols etc.) but the actual interface hardware too. Like ripping off the engine from your car while driving. For those reasons this issue is very hard for RXTX or any other serial comms library to handle. We could detect errors from kernel that indicate the UART has vanished and proceed to do automatic reopening of the serial port after some delay at the native lib. But: this has multiple issues, which probably will break user protocols and software. One of those is the fact that reopening the port could toggle its CTS/RTS/DTR/DSR signals causing unexpected trouble on user side. Other one is that we might end up in infinite loop of comm error <-> automatic reopening without notifying rxtx java side. Not elegant. Not proper. -- I'm proposing a following solution: We could implement a method to detect lost UART in event loop at native lib side and introduce a new Java side SerialPortEvent type UART_DISCONNECT. The native lib would send that event in case of error and proceed to automatically close the serial port and clear the invalid handles etc. (reset to fault free state). That would allow user code to gracefully handle these situations, by doing whatever is necessary to restore communications with their protocols etc. Usually that includes opening the serial port and doing some initializations. Those who choose to ignore that event, or not implement any handling for it, can continue to use RXTX as any other serial comms lib. But their software would still tumble and fall on UART disconnects - mostly caused by USB->UART bridges. Atleast, we'd have a method for implementing proper recovery if RXTX user chooses to do so. Beats duct tape+USB dongle combo anytime;) Feedback welcome :) -- I > > > On Tue, 15 Sep 2009, Daniel Weinand wrote: >> >> Error 0x5 at ..\src\termios.c(2712): Access Denied >> Error 0x5 at ..\src\termios.c(517): Access Denied >> ... > > It is a known problem. The kernel driver isnt restoring the fd. > See the previous post for what is required prior to being able to > handle it in your code. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 16 01:18:14 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 16 Sep 2009 10:18:14 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time In-Reply-To: References: Message-ID: I'm referring to my previous post and to my proposal for handling these situations (detection + java side event): In addition to UART_DISCONNECT event I proposed, your suggestion about AlreadyClosedException is great. We'd still have to handle existing "opened port objects" in Java side even after sending the UART_DISCONNECT event. Making them throw AlreadyClosedException would do that elegantly. -- I Frings, Stefan, VF-DE kirjoitti 16.9.2009 kello 9.06: > > And when a port disappears while it is open, the library should > close it and throw an AlreadyClosedException. > > I think the Java application should be able to recover itself from > temporarily lost devices, and it should also be able to open devices > that have been plugged in AFTER the library was loaded. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at attglobal.net Wed Sep 16 03:47:59 2009 From: david at attglobal.net (David Schmidt) Date: Wed, 16 Sep 2009 05:47:59 -0400 Subject: [Rxtx] FTDI chipset speed - much slower? In-Reply-To: References: <4AB044A0.10509@attglobal.net> Message-ID: <4AB0B44F.9060201@attglobal.net> Trent Jarvi wrote: > On Tue, 15 Sep 2009, David Schmidt wrote: >> I'm suspecting I'm doing something wrong along the way that is >> reacting badly with this chipset. My initial, lazy question, before >> exposing my code to the harsh light of day: is there anything obvious >> I might be doing wrong to this chipset to make it run so slowly? Has >> anyone else run into the same problem? > > Given that rxtx does not treat usb special, it may be something to do > with the nature of USB serial dongles. One suspicion I've had is that > the event loop is competing for bandwidth by trying to check the UART > status which is on the other side of the USB line. > > 1/5th is fairly significant. This is just writing/reading? How large > are the transfers? The protocol is a little dance that happens with tiny packets, rapidly sending/receiving (http://adtpro.sourceforge.net/protocol.html#Get). Host sends: 2 bytes: current block number (LSB, MSB) 1 byte: half-block number (2 = bytes 0-255, 1 = bytes 256-511) up to 256 bytes: Half-block, RLE encoded two bytes: CRC (lo) CRC (hi) Apple sends: One byte: acknowledgement Two bytes: current block number (LSB, MSB) One byte: half-block number (2 = bytes 0-255, 1 = bytes 256-511) (repeat) As others have mentioned, it may be the chipset waiting until that 16-byte on-chip buffer fills up, as the acknowledgment packet is really small. And, the payload packet size can be really small if all bytes are the same - RLE encoding would pack an "empty" block into just a few bytes too. - David From ozgurovic at hotmail.com Wed Sep 16 05:09:37 2009 From: ozgurovic at hotmail.com (Ozgur Erkent) Date: Wed, 16 Sep 2009 14:09:37 +0300 Subject: [Rxtx] FTDI chipset speed - much slower? In-Reply-To: <4AB0B44F.9060201@attglobal.net> References: <4AB044A0.10509@attglobal.net> <4AB0B44F.9060201@attglobal.net> Message-ID: Has anybody tried to experiment the latency time of FTDI USB2Serial? (its latency wrt serial port) after preferably sending command from the computer, probably by keeping track of time after command is sent, its echo back time. In different languages would be good to compare them. ?zg?r Erkent > Date: Wed, 16 Sep 2009 05:47:59 -0400 > From: david at attglobal.net > To: rxtx at qbang.org > Subject: Re: [Rxtx] FTDI chipset speed - much slower? > > Trent Jarvi wrote: > > On Tue, 15 Sep 2009, David Schmidt wrote: > >> I'm suspecting I'm doing something wrong along the way that is > >> reacting badly with this chipset. My initial, lazy question, before > >> exposing my code to the harsh light of day: is there anything obvious > >> I might be doing wrong to this chipset to make it run so slowly? Has > >> anyone else run into the same problem? > > > > Given that rxtx does not treat usb special, it may be something to do > > with the nature of USB serial dongles. One suspicion I've had is that > > the event loop is competing for bandwidth by trying to check the UART > > status which is on the other side of the USB line. > > > > 1/5th is fairly significant. This is just writing/reading? How large > > are the transfers? > > The protocol is a little dance that happens with tiny packets, rapidly > sending/receiving (http://adtpro.sourceforge.net/protocol.html#Get). > > Host sends: > 2 bytes: current block number (LSB, MSB) > 1 byte: half-block number (2 = bytes 0-255, 1 = bytes 256-511) > up to 256 bytes: Half-block, RLE encoded > two bytes: > CRC (lo) > CRC (hi) > > Apple sends: > One byte: acknowledgement > Two bytes: current block number (LSB, MSB) > One byte: half-block number (2 = bytes 0-255, 1 = bytes 256-511) > > (repeat) > > As others have mentioned, it may be the chipset waiting until that > 16-byte on-chip buffer fills up, as the acknowledgment packet is really > small. And, the payload packet size can be really small if all bytes > are the same - RLE encoding would pack an "empty" block into just a few > bytes too. > > - David > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ More than messages?check out the rest of the Windows Live?. http://www.microsoft.com/windows/windowslive/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Wed Sep 16 05:15:23 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Wed, 16 Sep 2009 07:15:23 -0400 (EDT) Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby In-Reply-To: <0EB22ACB-0676-44DE-BBD3-A9D38CFD2E88@myller.com> Message-ID: <11479259.481253099719746.JavaMail.gjohnson@pippin.local> This is a big problem for us, and one we have resorted to the duct tape solution for as we can't find anything better :( The notion of an additional event coming up from the native code sounds very promising! Cheers, greg -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com ----- Original Message ----- From: "Ilkka Myller" To: "Trent Jarvi" , "Daniel Weinand" , "Stefan Frings, VF-DE" Cc: "rxtx at qbang.org" Sent: Wednesday, September 16, 2009 3:06:41 AM GMT -05:00 US/Canada Eastern Subject: Re: [Rxtx] Error 0x5 in termios.c after wake-up from standby Windows is not my primary platform, but I agree with Trent. I tested this too and noticed that ClearCommError() does not fail because RXTX loses fd (why would it), but because fd seems to no longer exist, or is reused, on kernel side. Resulting in access denied(5) error. Definitely something RXTX has no control of. Also the USB device re-registers itself, causing all it's previous file handles invalidated. After few seconds after waking from sleep, new ones can be created with CreateFile calls - as expected. FTDI chips can be reprogrammed not to do this reconnection cycle on USB sleep (with mprog 3.5 software). I dont know how well Windows follows that setting. Also Windows allows disabling USB power saving on specific USB devices. After those settings, it entirely up to the USB driver to do the right thing. .. which I'm not entirely sure it will - even if it's technically possible to retain fd's over sleep the driver might still be hardwired to reconnect the device on power save events. -- Basicly all these issues are about the fact that someone/something rips off the UART hardware RXTX is controlling. The serial comms features on most operating systems are not equipped to handle this since UART is expected to be integral part of the system. Well, USB has certainly changed that. Now not only the serial device can be unplugged (which is handled properly by protocols etc.) but the actual interface hardware too. Like ripping off the engine from your car while driving. For those reasons this issue is very hard for RXTX or any other serial comms library to handle. We could detect errors from kernel that indicate the UART has vanished and proceed to do automatic reopening of the serial port after some delay at the native lib. But: this has multiple issues, which probably will break user protocols and software. One of those is the fact that reopening the port could toggle its CTS/RTS/DTR/DSR signals causing unexpected trouble on user side. Other one is that we might end up in infinite loop of comm error <-> automatic reopening without notifying rxtx java side. Not elegant. Not proper. -- I'm proposing a following solution: We could implement a method to detect lost UART in event loop at native lib side and introduce a new Java side SerialPortEvent type UART_DISCONNECT. The native lib would send that event in case of error and proceed to automatically close the serial port and clear the invalid handles etc. (reset to fault free state). That would allow user code to gracefully handle these situations, by doing whatever is necessary to restore communications with their protocols etc. Usually that includes opening the serial port and doing some initializations. Those who choose to ignore that event, or not implement any handling for it, can continue to use RXTX as any other serial comms lib. But their software would still tumble and fall on UART disconnects - mostly caused by USB->UART bridges. Atleast, we'd have a method for implementing proper recovery if RXTX user chooses to do so. Beats duct tape+USB dongle combo anytime;) Feedback welcome :) -- I On Tue, 15 Sep 2009, Daniel Weinand wrote: Error 0x5 at ..\src\termios.c(2712): Access Denied Error 0x5 at ..\src\termios.c(517): Access Denied ... It is a known problem. The kernel driver isnt restoring the fd. See the previous post for what is required prior to being able to handle it in your code. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Wed Sep 16 05:42:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 16 Sep 2009 05:42:08 -0600 (MDT) Subject: [Rxtx] FTDI chipset speed - much slower? In-Reply-To: References: Message-ID: On Wed, 16 Sep 2009, Frings, Stefan, VF-DE wrote: > Hello David, > ? > Im not 100% sure, but I highly assume that the delays are produces by the > USB communication. USB transfers data in packets and there are large > buffers of several hundreds characters, similar to ethernet. There is no > real time communication. > ? > So when your software thinks that it has sent a character, this was not > the case. It was only put into a buffer and will appears at the end of > your USB2Serial cable after some time - I assume somewhat around 0,3ms. > ? > I noticed the same behavious with different USB2Serial adapters on Linux > with plain C programs (not anything around Java and RxTx). > ? I have seen some simple native C applications that do not inspect the LSR manage to send bytes closer to how an onboard UART does. In that case it was just two bytes being observed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Sep 16 05:55:14 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 16 Sep 2009 05:55:14 -0600 (MDT) Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby In-Reply-To: <0EB22ACB-0676-44DE-BBD3-A9D38CFD2E88@myller.com> References: <4AAF5838.7080707@gmail.com> <0EB22ACB-0676-44DE-BBD3-A9D38CFD2E88@myller.com> Message-ID: I think that will be fine. I'm not sure about all the corner cases with bluetooth dongles. On Wed, 16 Sep 2009, Ilkka Myller wrote: > Windows is not my primary platform, but I agree with Trent. > > I tested this too and noticed that ClearCommError() does not fail because > RXTX loses fd (why would it), but because fd seems to no longer exist, or > is reused, on kernel side. Resulting in access denied(5) error. > Definitely something RXTX has no control of. > Also the USB device re-registers itself, causing all it's previous file > handles invalidated. After few seconds after waking from sleep, new ones > can be created with CreateFile calls - as expected. > > FTDI chips can be reprogrammed not to do this reconnection cycle on USB > sleep (with mprog 3.5 software). I dont know how well Windows follows > that setting. Also Windows allows disabling USB power saving on specific > USB devices. > > After those settings, it entirely up to the USB driver to do the right > thing. .. which I'm not entirely sure it will - even if it's technically > possible to retain fd's over sleep the driver might still be hardwired to > reconnect the device on power save events. > > -- > > Basicly all these issues are about the fact that someone/something rips > off the UART hardware RXTX is controlling. The serial comms features on > most operating systems are not equipped to handle this since UART is > expected to be integral part of the system. Well, USB has certainly > changed that.? > Now not only the serial device can be unplugged (which is handled > properly by protocols etc.) but the actual interface hardware too. Like > ripping off the engine from your car while driving. > > For those reasons this issue is very hard for RXTX or any other serial > comms library to handle. We could detect errors from kernel that indicate > the UART has vanished and proceed to do automatic reopening of the serial > port after some delay at the native lib. But: this has multiple issues, > which probably will break user protocols and software. One of those is > the fact that reopening the port could toggle its CTS/RTS/DTR/DSR signals > causing unexpected trouble on user side. Other one is that we might end > up in infinite loop of comm error <-> automatic reopening without > notifying rxtx java side. Not elegant. Not proper. > > -- > > I'm proposing a following solution: > > We could implement a method to detect lost UART in event loop at native > lib side and introduce a new Java side SerialPortEvent type > UART_DISCONNECT.?The native lib would send that event in case of error > and proceed to automatically close the serial port and clear the invalid > handles etc. (reset to fault free state). > > That would allow user code to gracefully handle these situations, by > doing whatever is necessary to restore communications with their > protocols etc. Usually that includes opening the serial port and doing > some initializations. > > Those who choose to ignore that event, or not implement any handling for > it, can continue to use RXTX as any other serial comms lib. But their > software would still tumble and fall on UART disconnects - mostly caused > by USB->UART bridges. > > Atleast, we'd have a method for implementing proper recovery if RXTX user > chooses to do so. Beats duct tape+USB dongle combo anytime;) > > Feedback welcome :)? > > -- > I > > > > On Tue, 15 Sep 2009, Daniel Weinand wrote: > > Error 0x5 at ..\src\termios.c(2712): Access > Denied > > Error 0x5 at ..\src\termios.c(517): Access Denied > > ... > > > It is a known problem. ?The kernel driver isnt restoring the > fd. ?See the previous post for what is required prior to > being able to handle it in your code. > > > From tjarvi at qbang.org Wed Sep 16 18:10:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 16 Sep 2009 18:10:42 -0600 (MDT) Subject: [Rxtx] Fwd: [Patch] Implement new UART_DISCONNECT event (fwd) Message-ID: Attachments are pending. They got caught by the size restrictions. > L?hett?j?: Ilkka Myller > P?iv?ys: 17. syyskuuta 2009 0.14.50 UTC+3.00 > Vastaanottaja: "rxtx at qbang.org" > Aihe: [Patch] Implement new UART_DISCONNECT event > > > Summary: > > This patch adds support for new SerialPortEvent.UART_DISCONNECT event. > > Backwards compatibility: > > If RXTX user does not register event listener and request UART_DISCONNECT > events, the RXTX functions same as before. (=does not react to UART > disconnects - or behaviour is unspecified). > > Implementation: > > 1. The RXTX native lib eventLoop() checks for UART disconnection (for example > USB Adapter unplug/powersave) and sends UART_DISCONNECT event to interested > Java listeners. This happens as soon as serial ports file descriptor/handle > becomes invalid or points to no longer existing serial port driver io's. > Sometimes the UART drivers accept writes/reads few seconds after actual > disconnect (this is normal and depends on OS and the driver used). > > 2. The Java send_event() closes serial ports automatically and forwards the > UART_DISCONNECT event to user code/listener. > > 3. Subsequent calls to any RXTXPort IO function (except close() or > removeEventListener()) throws PortAlreadyClosedException which is subclass of > IOException --> no code changes necessary if IOExceptions are already handled > in user code. This is for backwards compatibility. > > 4. It's up to the user code to handle the proper recovery after receiving the > UART_DISCONNECT (usually involves trying to reopen the port and reinitialize > protocols) > > How UART disconnect is detected: > > eventLoop() uses conditionally defined CHECK_FD(int fd) function to check if > file descriptor points to valid (and existing) serial port. On windows this > means calling termios_check_fd() function and all others call > posix_check_fd() function. > > On linux/mac/other posix, CHECK_FD calls fstat, fcntl and ioctl (with > non-port-state-altering parameters) to check if file descriptor is valid and > device driver behind it responds properly. > > On windows, CHECK_FD calls GetCommState() to check if serial port handle is > still valid and port is accessible. > > If someone knows a better way (less overhead) to check if fd is valid, please > let me know:) Checking fd value >0 is not enough, since we have to detect if > UART driver actually responds even when we have fd > 0 too. > > Patch: > > The included patch is against CVS (@2009/09/16). > It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < > im-uart-disconnect1.patch' in rxtx-devel/src directory. > > The patch file does not include gnu/io/PortAlreadyClosedException.java, which > is included as separate attachment. > You must place this to rxtx-devel/src/gnu/io directory. > > Demonstration code: > > I've also included a simple demonstration code to test this feature. I've > tested it on Windows and on Mac OS X. > The SerialReconnectDemo(.java) writes few bytes to the serial port > continuously every 500ms. > If UART_DISCONNECT is received, it goes into reconnect() loop in separate > thread and tries to re-establish serial port connection. > If connection can be re-established, it continues operation normally. > It uses ReentrantLocks to properly synchronize serial port operations, which > is very useful with reconnect and writes --> if going to reconnect mode, > writes are blocked until connection is re-established. > > The demonstration code nicely survives from random disconnects of USB Serial > adapter. > > > Feedback: > > This is highly experimental implementation and details are likely to change. > Testing and any feedback is more than welcome. > Especially Trent, any thoughts? Am I missing something here? > > > > Thanks, > > -- > I > > > > > > > > From stefan.frings at vodafone.com Thu Sep 17 00:22:40 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Thu, 17 Sep 2009 08:22:40 +0200 Subject: [Rxtx] RXTX on Ubuntu 9.04 with lock in /var/lock/LCK..ttyS0 In-Reply-To: References: Message-ID: Hello petter, I installed the C library through using apt and I copied the jar file to the lib folder of my Java application. The I added myself to the dialout group. Nothing else. --- Good morning. Tanks for help me. I added the User and now with RXTX did not signal more trouble to lock the serial port, but my Java application can no longer capture the data (in my case shipped weight of an electronic scale). It is very strange, because Windows works normally, you know if Linux is needed any more setup RXTX to work well? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.frings at vodafone.com Thu Sep 17 00:25:56 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Thu, 17 Sep 2009 08:25:56 +0200 Subject: [Rxtx] FTDI chipset speed - much slower? Message-ID: Hello Ozgur, I can tell you a value from Silabs CP2102 chip. With a simple loopback connection on the serial end and a bitrate of 115200 (everything else left to the default settings), using Linux, the echo of 1-10 characters comes always back withing one milliseconds in a Java application using RxTxComm. I am not able to measure it more exactly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.frings at vodafone.com Thu Sep 17 00:31:35 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Thu, 17 Sep 2009 08:31:35 +0200 Subject: [Rxtx] RxTx handling disconnected USB devices Message-ID: Hello Ilkka, I highly appreciate your recommendation. The Java application should decide what to do when the device gets disconnected. When I disconnect /dev/ttyUSB0 and then reconnect it, I want to be able to re-open that port. Currently, this is not the case, because RxTxComm does not close it when I disconnect the device. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Thu Sep 17 00:44:24 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 17 Sep 2009 09:44:24 +0300 Subject: [Rxtx] [Patch] New feature: Implemented UART_DISCONNECT event Message-ID: <6E51B6F1-41C3-4FD5-B4A9-CBFD4AF83C85@myller.com> Summary: This patch implements new SerialPortEvent.UART_DISCONNECT event. Backwards compatibility: If RXTX user does not register event listener and request UART_DISCONNECT events, the RXTX functions same as before. (=does not react to UART disconnects - or behaviour is unspecified). Implementation: 1. The RXTX native lib eventLoop() checks for UART disconnection (for example USB Adapter unplug/powersave) and sends UART_DISCONNECT event to interested Java listeners. This happens as soon as serial ports file descriptor/handle becomes invalid or points to no longer existing serial port driver io's. Sometimes the UART drivers accept writes/ reads few seconds after actual disconnect (this is normal and depends on OS and the driver used). 2. The Java send_event() closes serial ports automatically and forwards the UART_DISCONNECT event to user code/listener. 3. Subsequent calls to any RXTXPort IO function (except close() or removeEventListener()) throws PortAlreadyClosedException which is subclass of IOException --> no code changes necessary if IOExceptions are already handled in user code. This is for backwards compatibility. 4. It's up to the user code to handle the proper recovery after receiving the UART_DISCONNECT (usually involves trying to reopen the port and reinitialize protocols) How UART disconnect is detected: eventLoop() uses conditionally defined CHECK_FD(int fd) function to check if file descriptor points to valid (and existing) serial port. On windows this means calling termios_check_fd() function and all others call posix_check_fd() function. On linux/mac/other posix, CHECK_FD calls fstat, fcntl and ioctl (with non-port-state-altering parameters) to check if file descriptor is valid and device driver behind it responds properly. On windows, CHECK_FD calls GetCommState() to check if serial port handle is still valid and port is accessible. If someone knows a better way (less overhead) to check if fd is valid, please let me know:) Checking fd value >0 is not enough, since we have to detect if UART driver actually responds even when we have fd > 0 too. Patch: The patch file is against CVS (@2009/09/16). It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < im- uart-disconnect1.patch' in rxtx-devel/src directory. The patch file does not include gnu/io/ PortAlreadyClosedException.java, which is included as separate file. You must place this to rxtx-devel/src/gnu/io directory. Due to mailing list restrictions, the attachments are inside .tar.gz archive. Demonstration code: I've also included a simple demonstration code to test this feature. I've tested it on Windows and on Mac OS X. The SerialReconnectDemo(.java) writes few bytes to the serial port continuously every 500ms. If UART_DISCONNECT is received, it goes into reconnect() loop in separate thread and tries to re-establish serial port connection. If connection can be re-established, it continues operation normally. It uses ReentrantLocks to properly synchronize serial port operations, which is very useful with reconnect and writes --> if going to reconnect mode, writes are blocked until connection is re-established. The demonstration code nicely survives from random disconnects of USB Serial adapter. Feedback: This is highly experimental implementation and details are likely to change. Testing and any feedback is more than welcome. Especially Trent, any thoughts? Am I missing something here? Thanks, -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im-uart-disconnect-1.tar.gz Type: application/x-gzip Size: 11834 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Thu Sep 17 00:49:25 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 17 Sep 2009 07:49:25 +0300 Subject: [Rxtx] [Patch] New feature: Implemented UART_DISCONNECT event Message-ID: <7E5DCEB5-650B-41F5-A2F3-861B96BAA00F@myller.com> Summary: This patch adds support for new SerialPortEvent.UART_DISCONNECT event. Backwards compatibility: If RXTX user does not register event listener and request UART_DISCONNECT events, the RXTX functions same as before. (=does not react to UART disconnects - or behaviour is unspecified). Implementation: 1. The RXTX native lib eventLoop() checks for UART disconnection (for example USB Adapter unplug/powersave) and sends UART_DISCONNECT event to interested Java listeners. This happens as soon as serial ports file descriptor/handle becomes invalid or points to no longer existing serial port driver io's. Sometimes the UART drivers accept writes/ reads few seconds after actual disconnect (this is normal and depends on OS and the driver used). 2. The Java send_event() closes serial ports automatically and forwards the UART_DISCONNECT event to user code/listener. 3. Subsequent calls to any RXTXPort IO function (except close() or removeEventListener()) throws PortAlreadyClosedException which is subclass of IOException --> no code changes necessary if IOExceptions are already handled in user code. This is for backwards compatibility. 4. It's up to the user code to handle the proper recovery after receiving the UART_DISCONNECT (usually involves trying to reopen the port and reinitialize protocols) How UART disconnect is detected: eventLoop() uses conditionally defined CHECK_FD(int fd) function to check if file descriptor points to valid (and existing) serial port. On windows this means calling termios_check_fd() function and all others call posix_check_fd() function. On linux/mac/other posix, CHECK_FD calls fstat, fcntl and ioctl (with non-port-state-altering parameters) to check if file descriptor is valid and device driver behind it responds properly. On windows, CHECK_FD calls GetCommState() to check if serial port handle is still valid and port is accessible. If someone knows a better way (less overhead) to check if fd is valid, please let me know:) Checking fd value >0 is not enough, since we have to detect if UART driver actually responds even when we have fd > 0 too. Patch: The included patch is against CVS (@2009/09/16). It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < im- uart-disconnect1.patch' in rxtx-devel/src directory. The patch file does not include gnu/io/ PortAlreadyClosedException.java, which is included as separate attachment. You must place this to rxtx-devel/src/gnu/io directory. Demonstration code: I've also included a simple demonstration code to test this feature. I've tested it on Windows and on Mac OS X. The SerialReconnectDemo(.java) writes few bytes to the serial port continuously every 500ms. If UART_DISCONNECT is received, it goes into reconnect() loop in separate thread and tries to re-establish serial port connection. If connection can be re-established, it continues operation normally. It uses ReentrantLocks to properly synchronize serial port operations, which is very useful with reconnect and writes --> if going to reconnect mode, writes are blocked until connection is re-established. The demonstration code nicely survives from random disconnects of USB Serial adapter. Feedback: This is highly experimental implementation and details are likely to change. Testing and any feedback is more than welcome. Especially Trent, any thoughts? Am I missing something here? Thanks, -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im-uart-disconnect-1.patch Type: application/octet-stream Size: 44545 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PortAlreadyClosedException.java Type: application/octet-stream Size: 3606 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialReconnectDemo.java Type: application/octet-stream Size: 5781 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Sep 17 23:20:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 17 Sep 2009 21:20:53 -0600 (MDT) Subject: [Rxtx] [Patch] New feature: Implemented UART_DISCONNECT event In-Reply-To: <7E5DCEB5-650B-41F5-A2F3-861B96BAA00F@myller.com> References: <7E5DCEB5-650B-41F5-A2F3-861B96BAA00F@myller.com> Message-ID: On Thu, 17 Sep 2009, Ilkka Myller wrote: > > Summary: > > This patch adds support for new SerialPortEvent.UART_DISCONNECT event. > > Backwards compatibility: > > If RXTX user does not register event listener and request UART_DISCONNECT > events, the RXTX functions same as before. (=does not react to UART > disconnects - or behaviour is unspecified). > We have a section of methods that are extensions to the API at the bottom of the file. These are commented clearly as extensions for javadoc. The register method should go there. > Implementation: > > 1. The RXTX native lib eventLoop() checks for UART disconnection (for > example USB Adapter unplug/powersave) and sends UART_DISCONNECT event to > interested Java listeners. This happens as soon as serial ports file > descriptor/handle becomes invalid or points to no longer existing serial > port driver io's. Sometimes the UART drivers accept writes/reads few > seconds after actual disconnect (this is normal and depends on OS and the > driver used). > > 2. The Java send_event() closes serial ports automatically and forwards > the UART_DISCONNECT event to user code/listener. > > 3. Subsequent calls to any RXTXPort IO function (except close() or > removeEventListener()) throws PortAlreadyClosedException which is subclass > of IOException --> no code changes necessary if IOExceptions are already > handled in user code. This is for backwards compatibility. > I suspect this is a bit of a problem as it forces people to handle IOExceptions they normally didnt. Hmm. We may want to look at that again. I personally am OK with it but I think people should look it over. > 4. It's up to the user code to handle the proper recovery after receiving > the UART_DISCONNECT (usually involves trying to reopen the port and > reinitialize protocols) > > How UART disconnect is detected: > > eventLoop() uses conditionally defined CHECK_FD(int fd) function to check > if file descriptor points to valid (and existing) serial port. On windows > this means calling termios_check_fd() function and all others call > posix_check_fd() function. > > On linux/mac/other posix, CHECK_FD calls fstat, fcntl and ioctl (with > non-port-state-altering parameters) to check if file descriptor is valid > and device driver behind it responds properly. > > On windows, CHECK_FD calls GetCommState() to check if serial port handle > is still valid and port is accessible. > > If someone knows a better way (less overhead) to check if fd is valid, > please let me know:) Checking fd value >0 is not enough, since we have to > detect if UART driver actually responds even when we have fd > 0 too. > Looks good overall. I worry that there may be paths to deadlock on w32 as various layers try to redundantly make sure a write or read happens. I also worry that the new method signatures with exceptions will require code changes in older applications even though they extend IOExceptions. The windows checks are fine vs implementing a POSIX version. -- Trent Jarvi tjarvi at qbang.org From ilkka at myller.com Fri Sep 18 01:29:10 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 18 Sep 2009 08:29:10 +0300 Subject: [Rxtx] [Patch] New feature: Implemented UART_DISCONNECT event In-Reply-To: References: <7E5DCEB5-650B-41F5-A2F3-861B96BAA00F@myller.com> Message-ID: > > > We have a section of methods that are extensions to the API at the > bottom of the file. These are commented clearly as extensions for > javadoc. The register method should go there. > I agree. I'll move the method there. >> >> 3. Subsequent calls to any RXTXPort IO function (except close() or >> removeEventListener()) throws PortAlreadyClosedException which is >> subclass of IOException --> no code changes necessary if >> IOExceptions are already handled in user code. This is for >> backwards compatibility. >> > > I suspect this is a bit of a problem as it forces people to handle > IOExceptions they normally didnt. Hmm. We may want to look at that > again. I personally am OK with it but I think people should look it > over. > I do not think this is a problem for methods that already did throw IOException, but for those API extension-methods that previously did not? right? I did not add PortAlreadyClosed exception to any stuff that we inherit from Comm API. I assumed we can change our own extensions relatively freely if necessary. I changed the notify....() methods to handle the closed-serial-port - situation by making them do nothing in that case. They only change something if isOpen() returns true. Therefore they dont have to throw PortAlreadyClosedExceptions. That's fine, because they also dont have to return any values since they are void. But those RXTX extension methods that I modified to throw the new exception, usually return some values. If we make them to behave like notify..(), they still have to return something - with closed serial port. What value would that be? Determining proper return value for those is bit difficult since they obviously cant call native methods with fd==0.. So basicly, that is why I chose to throw PortAlreadyClosed exception from them. The alternative did not feel any better. I hate to change the API ... even RXTX extensions ... but I think it's the right thing to do here if we want to implement this feature. As an example, the current implementation with added new exception.... public byte getParityErrorChar( ) throws UnsupportedCommOperationException, PortAlreadyClosedException { byte ret; checkPortAlreadyClosed(); ret = nativeGetParityErrorChar(); return( ret ); } ..versus non PortAlreadyClosed -exception alternative.. public byte getParityErrorChar( ) throws UnsupportedCommOperationException { if ( isOpen() == true ) { byte ret; ret = nativeGetParityErrorChar(); return( ret ); } else { return ( ); } } Thats the problem. We could however, throw UnsupportedCommOperationException and keep the method interface intact. But that would break the contract for the usage/meaning of UnsupportedCommOperationException ... and causes even more trouble for users. > > I worry that there may be paths to deadlock on w32 as various layers > try to redundantly make sure a write or read happens. We dont want that. Did you notice that I replaced fd verification in read/write with new termios_check_fd()'s.? Any ideas? > The windows checks are fine vs implementing a POSIX version. > I still feel that those checks are not optimal. There should be a cleaner way to verify that device driver responds behind fd.. instead of just requesting status registers from it. -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Fri Sep 18 07:27:43 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 18 Sep 2009 13:27:43 +0200 Subject: [Rxtx] Checking jni calls Message-ID: <7a803d460909180427h6a43b0c8i89734888aac2ffd4@mail.gmail.com> Hi I am trying to troubleshoot our code that talks to several devices on the serial port using RXTX, and I came across a tip from sun to run the java code with the -Xcheck:jni flag set. The code did not run very long before failing. Does anyone know what line of code in the eventLoop is causing this failure (I'm running this code on Windows XP 32bit)? I would like to patch this and create a new personal build of RXTX that runs even with the check:jni flag set. ... Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 18 Sep 2009 11:16:57,244 DEBUG serial.DeviceSerialConnection, line 90 - Opening COM-port on COM22 FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1575) -- Kjetil ?ster?s From tjarvi at qbang.org Tue Sep 1 02:38:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 1 Sep 2009 02:38:40 -0600 (MDT) Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks Ilkka The problem should be resolved (confirmed from two locations). I'll be trying to hunt down a Snow Leopard box tomorrow evening as well. On Tue, 1 Sep 2009, Ilkka Myller wrote: > Hi, > > CVS server is reachable, but when trying anonymous login it replies: > > " > Fatal error, aborting. > anonymous: no such system user > " > > It seems that the anonymous cvs account is not yet properly configured on the > new system. > > -- > I > >> On Mon, 31 Aug 2009, Trent Jarvi wrote: >> >> The server has been beemed to another location for those experiencing >> routing problems. >> >> in bash: >> >> export CVSROOT=:pserver:anonymous at qbang.org:2401/var/cvs/cvsroot >> cvs login (no passwd) >> cvs co -r commapi-0-0-1 rxtx-devel >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Tue Sep 1 03:05:59 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 12:05:59 +0300 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks, The new CVS server works well :) I can also confirm that latest CVS version builds properly with unmodified Snow Leopard (Mac OS X 10.6) system: Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 gcc version 4.2.1 (Apple Inc. build 5646) Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) --> Resulting JNI library (Universal Binary): i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = 9d15fc488b301da8bf65b2c9456a7bbb --> Resulting JAR: RXTXComm.jar / 60942 bytes MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 Atleast it builds.. and probably works too. I have not tested that yet. -- I Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > The problem should be resolved (confirmed from two locations). I'll > be trying to hunt down a Snow Leopard box tomorrow evening as well. From jimmy.lee at emotum.com Tue Sep 1 05:07:19 2009 From: jimmy.lee at emotum.com (Jimmy Lee [emotum]) Date: Tue, 1 Sep 2009 21:07:19 +1000 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: <112685a90909010407i6054acb5tc2b12196797bfaf1@mail.gmail.com> Could we access to the binaries? Please :) 2009/9/1 Ilkka Myller > Thanks, > > The new CVS server works well :) > > I can also confirm that latest CVS version builds properly with unmodified > Snow Leopard (Mac OS X 10.6) system: > > Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_I386 i386 > gcc version 4.2.1 (Apple Inc. build 5646) > Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) > > > --> Resulting JNI library (Universal Binary): > > i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes > > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 > librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc > > MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = > 9d15fc488b301da8bf65b2c9456a7bbb > > > --> Resulting JAR: > > RXTXComm.jar / 60942 bytes > > MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 > > > > Atleast it builds.. and probably works too. I have not tested that yet. > > -- > I > > Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > > The problem should be resolved (confirmed from two locations). I'll be >> trying to hunt down a Snow Leopard box tomorrow evening as well. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Tue Sep 1 06:21:28 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Tue, 1 Sep 2009 08:21:28 -0400 (EDT) Subject: [Rxtx] Snow Leopard binaries Message-ID: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> +1 for binaries - pretty please with sugar on top... -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com From fredm at alum.mit.edu Tue Sep 1 06:24:17 2009 From: fredm at alum.mit.edu (Fred G. Martin) Date: Tue, 1 Sep 2009 08:24:17 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> Message-ID: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> You can find one here: http://iharder.sourceforge.net/current/java/ Also, you need to add yourself (any rxtx user) to the uucp group. Niutils don't exist, but dscl is a replacement. There is info for using it here: http://aplawrence.com/MacOSX/directory_services.html Fred On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Tue Sep 1 07:03:37 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Tue, 1 Sep 2009 18:33:37 +0530 Subject: [Rxtx] Help for RXTX on mac Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time I am able to read the device but on second time, it hangs on COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then it was showing the PortInUseException, I replaced the RXTX library to 2.2Pre1 so it is showing this problem. Is this is a problem with RXTX on Mac? Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: From ilkka at myller.com Tue Sep 1 07:57:06 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 16:57:06 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:02:31 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:02:31 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:43:49 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:43:49 +0300 Subject: [Rxtx] Help for RXTX on mac In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE@myller.com> Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Arseneau at Sun.COM Tue Sep 1 08:51:32 2009 From: Eric.Arseneau at Sun.COM (Eric Arseneau) Date: Tue, 01 Sep 2009 07:51:32 -0700 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24@sun.com> Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 09:24:30 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 18:24:30 +0300 Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D@myller.com> Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Thu Sep 3 02:50:16 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Thu, 3 Sep 2009 10:50:16 +0200 Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s From Kapil_Gupta at hcl.in Thu Sep 3 06:52:21 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:22:21 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From Kapil_Gupta at hcl.in Thu Sep 3 07:15:19 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:45:19 +0530 Subject: [Rxtx] Rxtx Digest, Vol 25, Issue 3 In-Reply-To: References: Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C50BB@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi myller, I have attached the code with the mail. Please help me if I am doing something wrong in it. Thanks & Regards, Kapil Gupta -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of rxtx-request at qbang.org Sent: Thursday, September 03, 2009 4:15 PM To: rxtx at qbang.org Subject: Rxtx Digest, Vol 25, Issue 3 Send Rxtx mailing list submissions to rxtx at qbang.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qbang.org/mailman/listinfo/rxtx or, via email, send a message with subject or body 'help' to rxtx-request at qbang.org You can reach the person managing the list at rxtx-owner at qbang.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Rxtx digest..." Today's Topics: 1. Re: Snow Leopard binaries (Ilkka Myller) 2. Re: Snow Leopard binaries (Ilkka Myller) 3. Re: Help for RXTX on mac (Ilkka Myller) 4. Re: Snow Leopard binaries (Eric Arseneau) 5. Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters (Ilkka Myller) 6. RXTX multiple crashes (Kjetil ?ster?s) 7. RXTX 2.2Pre + MacMini+ Deadlock while second time port open (Kapil Gupta) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Sep 2009 16:57:06 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 1 Sep 2009 17:02:31 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <55EC133D-DC83-45A3-849C-02714904D580 at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 1 Sep 2009 17:43:49 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Help for RXTX on mac Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Tue, 01 Sep 2009 07:51:32 -0700 From: Eric Arseneau Cc: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24 at sun.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 1 Sep 2009 18:24:30 +0300 From: Ilkka Myller To: rxtx Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Thu, 3 Sep 2009 10:50:16 +0200 From: Kjetil ?ster?s To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s ------------------------------ Message: 7 Date: Thu, 3 Sep 2009 18:22:21 +0530 From: Kapil Gupta To: "rxtx at qbang.org" Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059 at NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset="us-ascii" Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: ------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx End of Rxtx Digest, Vol 25, Issue 3 *********************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From ilkka at myller.com Thu Sep 3 11:17:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 3 Sep 2009 20:17:27 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <4520677F-E8F0-46F5-B4AD-3AD3A7C2AED3@myller.com> Hi Kapil, The code is incomplete and I did not find anything I could to test/ debug with this. I also tried to find the actual serial port opening, but found only a call to missing method which creates the SerialPort object (?): serialPort = getSerialPortConnection( COMPort, this.readEvent.getDeviceName(), SerialCommConfig.DEVICE1[SerialCommConfig.TIMEOUT], SerialCommConfig.DEVICE1[SerialCommConfig.BAUDRATE], SerialCommConfig.DEVICE1[SerialCommConfig.DATABITS], SerialCommConfig.DEVICE1[SerialCommConfig.STOPBITS], SerialCommConfig.DEVICE1[SerialCommConfig.PARITY] ); The class SerialCommConfig is missing too. If this is a part of the actual code you are using, please note that you are not actually closing the serial port. The call to close() method is commented out: try { // serialPort.close(); } catch (Exception ex) { ex.printStackTrace(); } Re-opening of the serial port wont work if you haven't properly closed it first. -- I > > I am using RXTX on Macintosh to communicate to my device. First time > the device responds well but on second time, it hangs on > COMPort.open (name, timeout). > > I have attached the source code in a file. Please help me. > > Thanks & Best Regards, > Kapil -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorton at intellimec.com Thu Sep 3 11:37:55 2009 From: dmorton at intellimec.com (Daniel Morton) Date: Thu, 3 Sep 2009 13:37:55 -0400 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. (I haven't tried previous version though). Daniel Morton Java/J2EE Developer Tel +1 519.745.8887 x4331 Email dmorton at intellimec.com www.intellimec.com | www.iLane.com | www.drivesync.com Intelligent Mechatronic Systems Inc. 435 King Street North Waterloo, ON N2J 2Z5 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s Sent: Thursday, September 03, 2009 4:50 AM To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. From alexanderkiel at gmx.net Fri Sep 4 02:29:15 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 10:29:15 +0200 Subject: [Rxtx] Official Javadoc Location Message-ID: <1252052955.4025.80.camel@T61-KIEL> Hi List, I wasn't able to find an official location of RXTX Javadoc accessible over HTTP. Maybe someone can link me to it. If there is no such location, I would like to see one. I like to link from my own Javadoc to such a location. Thanks Alexander - e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:19:25 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:19:25 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> Message-ID: <1252055965.4025.84.camel@T61-KIEL> Hi Michael, thanks for the pointer. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 09:48 +0100, Michael Tandy wrote: > RxTx javadoc: http://users.frii.com/jarvi/rxtx/doc/index.html > Javax interface RxTx duplicates javadoc: > http://java.sun.com/products/javacomm/reference/api/index.html > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:22:14 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:22:14 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> Message-ID: <1252056134.4025.87.camel@T61-KIEL> Hi Eike, thanks, but I need a direct package pointer so that Javadoc will link the gnu.io packages automatically to the right location. Michael has pointed me to http://users.frii.com/jarvi/rxtx/doc/index.html which has the gnu.io packages. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 11:04 +0200, Eike Hinderk J?rrens wrote: > Hi Alexander, > it seems to me that RXTX is implementing this API: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Kind regards, > Eike > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kjetilos at gmail.com Fri Sep 4 03:43:41 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 11:43:41 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> Message-ID: <7a803d460909040243ke4449ecucbe2cd8b15761746@mail.gmail.com> Hi Daniel, This is interesting, what type of application are you making? Is there a lot of signaling on different COM ports at the same time in your application? In our application we have 11 devices connected to different COM ports, 9 of these are in active use when the application is running. I'm wondering how to use the RXTX library version 2.1.7 in this scenario without causing it to crash. After adding more signaling on the COM ports in our application we have now experienced other crashes and it is natural to think that it has something to do with our way of using RXTX from several threads at the same time. So my question is are there any methods like read/write/flush/close that are not thread safe and should be handled with care? And similarly is the RXTXPort.SerialInputStream and RXTXPort.SerialOutputStream thread safe? 2009/9/3 Daniel Morton : > I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. ?(I haven't tried previous version though). > > Daniel Morton > Java/J2EE Developer > > Tel ? ?+1 519.745.8887 x4331 > Email ? ?dmorton at intellimec.com > > > www.intellimec.com ?| ?www.iLane.com ?| ?www.drivesync.com > > > > Intelligent Mechatronic Systems Inc. > 435 King Street North Waterloo, ON N2J 2Z5 > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s > Sent: Thursday, September 03, 2009 4:50 AM > To: rxtx at qbang.org > Subject: [Rxtx] RXTX multiple crashes > > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x7d0d] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0ce75800): ?JavaThread "Y Worker" daemon > [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 > > Registers: > EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 > ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 > EIP=0x10007d0d, EFLAGS=0x00010202 > > Top of Stack: (sp=0x0d7ff6d8) > 0x0d7ff6d8: ? 0d7ff700 00000000 00000000 00000000 > 0x0d7ff6e8: ? 02a2eae8 00000123 00002958 0d7ff718 > 0x0d7ff6f8: ? 7c830887 7c90d28a 7c8664b5 00000e2c > 0x0d7ff708: ? 00002958 00000000 00000000 7c90cffa > 0x0d7ff718: ? 7c809bdb 00002958 0d7ff758 00000e40 > 0x0d7ff728: ? 00002958 02bd0468 0ce75800 080e4ee0 > 0x0d7ff738: ? 00000000 00000000 00000000 00000000 > 0x0d7ff748: ? 00000000 00000000 00000014 7c90d09a > > Instructions: (pc=0x10007d0d) > 0x10007cfd: ? 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 > 0x10007d0d: ? 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 > > > Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x7d0d] > J ?gnu.io.RXTXPort.nativeDrain(Z)Z > J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > ... > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x9c55] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0cddf400): ?JavaThread "XXX Worker" daemon > [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 > > Registers: > EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 > ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 > EIP=0x10009c55, EFLAGS=0x00010206 > > Top of Stack: (sp=0x0bb8f830) > 0x0bb8f830: ? 00000000 00000000 c0000005 00000000 > 0x0bb8f840: ? 00000000 00f1f0a5 00000002 00000000 > 0x0bb8f850: ? 003a0100 0001003f 0bb8fb20 0b9ff918 > 0x0bb8f860: ? 00000000 00000000 0bb8fb68 0bb8fb20 > 0x0bb8f870: ? 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 > 0x0bb8f880: ? 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 > 0x0bb8f890: ? 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 > 0x0bb8f8a0: ? 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 > > Instructions: (pc=0x10009c55) > 0x10009c45: ? 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff > 0x10009c55: ? 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 > > > Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x9c55] > C ?[rxtxSerial.dll+0xa05e] > J ?gnu.io.RXTXPort.readByte()I > J ?gnu.io.RXTXPort$SerialInputStream.read()I > J ?java.io.FilterInputStream.read()I > ... > > -- > Kjetil ?ster?s > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kjetil ?ster?s From tjarvi at qbang.org Fri Sep 4 06:00:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Sep 2009 06:00:40 -0600 (MDT) Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x7d0d] > J gnu.io.RXTXPort.nativeDrain(Z)Z > J gnu.io.RXTXPort$SerialOutputStream.flush()V > Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x9c55] > C [rxtxSerial.dll+0xa05e] > J gnu.io.RXTXPort.readByte()I > J gnu.io.RXTXPort$SerialInputStream.read()I RXTX 2.1-7 has concurrency issues that will show upon multicore systems. These should be resolved in the 2.2 pre release. A user application could synchronize the read/write/open/close calls while using 2.1 to avoid the concurrency issue. The flush is probably following a write while the readByte is coming from read(byte b). The bugs existed in rxtx for a long time. I assume changes in the JVM and the presence of multicore systems exposed the issues. -- Trent Jarvi tjarvi at qbang.org From kjetilos at gmail.com Fri Sep 4 06:33:33 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 14:33:33 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <7a803d460909040533n1caf240y8168477a578bc45c@mail.gmail.com> Den 4. september 2009 14.00 skrev Trent Jarvi f?lgende: > > > On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > >> Hi >> >> We are using RXTX version 2.1.7 actively and lately we are having some >> issues with the RXTX library crashing. We are running a windows xp >> system with multiple COM ports where each COM port have a serial >> device connected. Lately we have increased the amount of signaling >> done over the COM ports and we are experiencing several odd crashes. I >> tried to search the mailinglist for something similar but was unable >> to find anything. At one time the RXTX crashed in the >> gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the >> gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack >> traces if someone is interested in having a look. Has anyone seen the >> same crashes? and does anyone know what can cause such crash? >> >> >> Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x7d0d] >> J ?gnu.io.RXTXPort.nativeDrain(Z)Z >> J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > >> Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x9c55] >> C ?[rxtxSerial.dll+0xa05e] >> J ?gnu.io.RXTXPort.readByte()I >> J ?gnu.io.RXTXPort$SerialInputStream.read()I > > > RXTX 2.1-7 has concurrency issues that will show upon multicore systems. > These should be resolved in the 2.2 pre release. ?A user application could > synchronize the read/write/open/close calls while using 2.1 to avoid the > concurrency issue. > > The flush is probably following a write while the readByte is coming from > read(byte b). > > The bugs existed in rxtx for a long time. ?I assume changes in the JVM and > the presence of multicore systems exposed the issues. > Ok, so we should look more into using a newer version of RXTX. The current version from the webpage is 2.2pre2, what is the stability status of this version. Is it good enough for use in a production environment? -- Kjetil ?ster?s From martinezrodolfo at gmail.com Fri Sep 4 13:39:57 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Fri, 4 Sep 2009 15:09:57 -0430 Subject: [Rxtx] Problem with data available event Message-ID: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Hello list members. I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a serial port USB adapter to communicate with an electronical inmunoassay analyzer. The program works porperly with one model of the analyzer series. It defines a protocol which every message sent should be replied with an ACK in order to continue with the communication. Now we are trying to communicate with another model of the same brand and series wich in theory should be much of the same of what was previously done. Unfortunately, that is not the case. The problem with this connection is that it never fires the Data Available serial port event. Is like if nothing was being received in the input stream. The following code always prints zero when the equipment should be transmitting. ----------------------- beginning of sample code ---------------------------------- SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", 10000); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); int len = 0; byte[] readBuffer = new byte[8]; while (true) { len = in.read(readBuffer); System.out.println(len); writer.writeACK(); // writing ACK to analyzer } ----------------------- end of sample code ------------------------------------------ We know that the analyzer is transmitting because HyperTerminal does shows the proper output. In fact, after running the above code and connecting via Hyperterminal all data is received in one block. Is like the data sent from the analyzer is being held somewhere in the way. Sniffing at the serial port, noticed that IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this helps to find what might be wrong or not, but here they are: On Hyperterminal: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 XonLimit:80 XoffLimit:200 On Java: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 XonLimit:0 XoffLimit:0 Thanks in advance for your help. Rodolfo M From ilkka at myller.com Sat Sep 5 04:36:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 5 Sep 2009 13:36:27 +0300 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <121198EE-65A4-463B-ACC7-29FFB9855B2C@myller.com> Hi Rodolfo, By default RXTX does not enable any flow control for the serial port. Please check what flow control you have active in HyperTerminal when you are able to receive data and then use the same flow control with RXTX serial port: serialPort.setFlowControlMode(int flowcontrol); Possible flowcontrol flags are (from SerialPort class) FLOWCONTROL_NONE FLOWCONTROL_RTSCTS_IN FLOWCONTROL_RTSCTS_OUT FLOWCONTROL_XONXOFF_IN FLOWCONTROL_XONXOFF_OUT For example, you can try enabling RTS/CTS hardware flow control. Note the bitwise OR operator ' | ': serialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Also if your device requires RTS/CTS flow control make sure you have fully connected serial cable (not just RX, TX, GND for example, but also RTS, CTS, DTR). One thing you might want to check is the state of DTR (Data Terminal Ready). Some devices wait for the DTR signal before they send any data. You can enable or disable DTR signal (high/low) with: serialPort.setDTR( boolean state ); -- I > Hello list members. > > I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a > serial port USB adapter to communicate with an electronical > inmunoassay analyzer. The program works porperly with one model of the > analyzer series. It defines a protocol which every message sent should > be replied with an ACK in order to continue with the communication. > Now we are trying to communicate with another model of the same brand > and series wich in theory should be much of the same of what was > previously done. Unfortunately, that is not the case. The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. > > ----------------------- beginning of sample code > ---------------------------------- > SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", > 10000); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > InputStream in = serialPort.getInputStream(); > OutputStream out = serialPort.getOutputStream(); > > int len = 0; > byte[] readBuffer = new byte[8]; > while (true) { > len = in.read(readBuffer); > System.out.println(len); > > writer.writeACK(); // writing ACK to analyzer > } > ----------------------- end of sample code > ------------------------------------------ > > We know that the analyzer is transmitting because HyperTerminal does > shows the proper output. In fact, after running the above code and > connecting via Hyperterminal all data is received in one block. Is > like the data sent from the analyzer is being held somewhere in the > way. Sniffing at the serial port, noticed that > IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this > helps to find what might be wrong or not, but here they are: > > On Hyperterminal: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 > XonLimit:80 XoffLimit:200 > > On Java: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 > XonLimit:0 XoffLimit:0 > > > Thanks in advance for your help. > Rodolfo M > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.weber99 at gmx.net Sun Sep 6 13:51:12 2009 From: karl.weber99 at gmx.net (Karl Weber) Date: Sun, 6 Sep 2009 21:51:12 +0200 Subject: [Rxtx] Cannot create lock file Message-ID: <200909062151.12228.karl.weber99@gmx.net> Hi, I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an opensuse repository as well as from the homepage of the rxtx project. I have already added the user to the group uucp, however, it does not have any effect. What else do I have to do to make it work? (It does work with user root, though.) The error message is: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL Thanks in advance, Karl From tjarvi at qbang.org Sun Sep 6 13:51:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 6 Sep 2009 13:51:42 -0600 (MDT) Subject: [Rxtx] Cannot create lock file In-Reply-To: <200909062151.12228.karl.weber99@gmx.net> References: <200909062151.12228.karl.weber99@gmx.net> Message-ID: On Sun, 6 Sep 2009, Karl Weber wrote: > Hi, > > I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an > opensuse repository as well as from the homepage of the rxtx project. > > I have already added the user to the group uucp, however, it does not have > any effect. What else do I have to do to make it work? (It does work with > user root, though.) > > The error message is: > > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to > create lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > > Thanks in advance, Karl Look at the group that owns /var/lock with ls -ld /var/lock The following should work as a user when they are in the correct group: touch /var/lock/test && rm -f /var/lock/test -- Trent Jarvi tjarvi at qbang.org From Luca.Catoni at sysdat.it Mon Sep 7 06:32:42 2009 From: Luca.Catoni at sysdat.it (Luca Catoni) Date: Mon, 7 Sep 2009 14:32:42 +0200 Subject: [Rxtx] time-out implementation Message-ID: I need to implement a simple timer class to manage time-out in my RS-232 serial communication with a remote device using the rxtx library. The functions that the timer should have are start(), and reset() and start() method must throw an exception (TimeoutException) when it expires. I am not an expert in concurrent programming and I do not have much knowledge on threads. myTimer.setExpirationTime(myvalue); ? public void serialEvent(SerialPortEvent event) { if (event.getEventType() == SerialPortEvent.OUTPUT_BUFFER_EMPTY) { // transmission ? out.write(?); try{ myTimer.start(); }catch(TimeoutException te){ myTimer.reset(); ? } ? if (event.getEventType() == SerialPortEvent.DATA_AVAILABLE) { // receiving in.read(?); if (mycondition){ myTimer.stop();//ok, timer NOT expired myTimer.reset();//now I can call start() method again in //transmission to restart my timer when I //have to transmit next data } Can anyone help me to implement the class MyTimer? thanks in advance. -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Mon Sep 7 06:49:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Mon, 7 Sep 2009 18:19:24 +0530 Subject: [Rxtx] 2.2Pre + MacMini+ Deadlock while second time port Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E22FB6F@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, Please find the updated code (close call was commented by mistake). This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From michael.erskine at ketech.com Mon Sep 7 09:13:03 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 7 Sep 2009 16:13:03 +0100 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Rodolfo Mart?nez > Subject: [Rxtx] Problem with data available event > The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. Hi Rodolfo, The sample code you provided doesn't implement or register any event listeners. Regards, Michael Erskine. From martinezrodolfo at gmail.com Mon Sep 7 10:21:22 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Mon, 7 Sep 2009 11:51:22 -0430 Subject: [Rxtx] Problem with data available event In-Reply-To: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> Message-ID: <30eacee0909070921l7f285765ue2c661963183fd2b@mail.gmail.com> On Mon, Sep 7, 2009 at 10:43 AM, Michael Erskine wrote: > Hi Rodolfo, > The sample code you provided doesn't implement or register any event listeners. > > Regards, > Michael Erskine. Hi Michael, I didn't write the event listeners declaration on the sample code for simplicity, but I do implement them on my real code. I should have mentioned it on the sample code anyway... my bad. I haven't had access to the device I'm trying to connect, but tomorrow will. And hope that with the explanation of Ilkka Myller will succeed this time. Thanks for your attention. Rodolfo M From ajmas at sympatico.ca Mon Sep 7 16:58:13 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 7 Sep 2009 18:58:13 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" I noticed in the page you posted posted you indicated that you patched two files. Did you submit the changes to Jarvi, so they could be included in the main code branch? Andr? From tjarvi at qbang.org Mon Sep 7 16:57:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Sep 2009 16:57:53 -0600 (MDT) Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On Mon, 7 Sep 2009, Andre-John Mas wrote: > > On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > >> Sorry, my rudeness was not intentional (a typo). >> Lets try again.. ;) >> >> "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > I noticed in the page you posted posted you indicated that you patched two > files. Did you submit the changes to Jarvi, so they could be included in the > main code branch? > Hi Andr? Ilkka is working with us to get changes in. I'm not sure about those two patches which may already be in CVS. I'll let him answer that. I've given him write access to CVS and asked him to cc the list non whitespace changes when they are ready. Right now he is asking questions off the list regarding cleaning up the Mac and w32 build files. -- Trent Jarvi tjarvi at qbang.org From nsp25 at cornell.edu Mon Sep 7 21:17:45 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Mon, 7 Sep 2009 23:17:45 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: (Sorry if this is a double post, but I sent my original message without subscribing, and since this is an urgent problem, I thought I'd resend after subscribing to bypass the moderator limbo zone) Hi all, I've asked my question on StackOverflow already, so rather than copy-paste the question here, I'd like to redirect you there . Short version, I am no longer able to receive anything over RS-232 with RXTX, but other programs work fine. I'm definitely sending things, because when I connect with a different program, all the responses to the commands I sent via RXTX arrive all at once. Everything was fine in the spring, so what could have happened? Windows update? -Nate -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.j.tandy at warwick.ac.uk Tue Sep 8 01:30:48 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Tue, 8 Sep 2009 08:30:48 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> OK, so: 1. It worked in spring but has stopped doing so and 2. The data all arrives at once when you start hyperterminal. Is it possible you're using a different serial cable to connect to the device, compared to the one you were using in spring? If so, the issue might be hardware flow control - that is, your device might be buffering data because it can't transmit it until your computer sets 'DTR' or 'RTS' or something like that. One way of bypassing hardware flow control is by using cables which cross over certain wires so that the right signals are always being sent; it's possible your old cable had these connections but your current cable doesn't have them. If you can find the old cable, you could put it back in and see if that fixes things? 2009/9/8 Nathaniel S. Parsons : > (Sorry if this is a double post, but I sent my original message without > subscribing, and since this is an urgent problem, I thought I'd resend after > subscribing to bypass the moderator limbo zone) > > Hi all, > > I've asked my question on StackOverflow already, so rather than copy-paste > the question here, I'd like to redirect you there. > > Short version, I am no longer able to receive anything over RS-232 with > RXTX, but other programs work fine. I'm definitely sending things, because > when I connect with a different program, all the responses to the commands I > sent via RXTX arrive all at once. > > Everything was fine in the spring, so what could have happened? Windows > update? > > -Nate > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Tue Sep 8 01:50:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 8 Sep 2009 10:50:33 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <111FEC9A-26BA-435C-BABC-314C7E4F23E5@myller.com> Hi all, Patches applied to the 2.1.7 binaries distributed by Robert Harder (http://iharder.sourceforge.net/current/java/ ) are already in the 2.2. Actually in 2.2 the issue with integer types handling seems to be fixed even more extensively than that single patch to 2.1.7 originally did. And yes, Trent has granted me CVS commit access. Thank you. First thing I'm going to focus on is the code quality and clean up: unused variables, invalid pointer usage etc.. Most of this just causing compile warnings - some harmless and some have potential for causing runtime problems. Instead of just blindly committing new changes to CVS, I've been discussing with Trent about the way things have been done in the RXTX CVS before. (how to handle white space patches, what needs to be discussed with the list first, proper locations for new files/ directories/subprojects, "the way things are done in RXTX"). But patches are coming and bugs will be fixed. I hope everyone will continue to submit the bugs they discover to this mailing list. Most important thing is to provide enough info (code;) so that the issue can be duplicated and eventually fixed. -- I > > > On Mon, 7 Sep 2009, Andre-John Mas wrote: >> >> I noticed in the page you posted posted you indicated that you >> patched two files. Did you submit the changes to Jarvi, so they >> could be included in the main code branch? >> > > Ilkka is working with us to get changes in. I'm not sure about > those two patches which may already be in CVS. I'll let him answer > that. > > I've given him write access to CVS and asked him to cc the list non > whitespace changes when they are ready. Right now he is asking > questions off the list regarding cleaning up the Mac and w32 build > files. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 15:35:19 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 17:35:19 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: Thanks for the response. I'll try to get to the electronics store tomorrow to get more serial cables, even if it isn't the problem. I am using a different serial cable than I was in the spring. It's actually a Male/Female cable with a female-female adapter since the old cables aren't around anymore. The hardware's manual says nothing except to use a "Straight cable" but I figured that if it worked in HyperTerminal, it should work in RXTX, right? Anyways, I've also noticed some things that are different between HyperTerminal, RXTX, and a separate program I found that communicates with the device (but doesn't do what I want, which is why I'm rolling my own program) HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and DTR indicators are green Other program - not sure what settings it thinks it's using, but only SPM's RTS indicator is green RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators are on. >From Serial Port Monitor's help files (paraphrased): the indicators display the state of the serial control lines RTS - Request To Send CTS - Clear To Send DTR - Data Terminal Ready Could this be related to the problem? -Nate On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > OK, so: > > 1. It worked in spring but has stopped doing so and > 2. The data all arrives at once when you start hyperterminal. > > Is it possible you're using a different serial cable to connect to the > device, compared to the one you were using in spring? > > If so, the issue might be hardware flow control - that is, your device > might be buffering data because it can't transmit it until your > computer sets 'DTR' or 'RTS' or something like that. > > One way of bypassing hardware flow control is by using cables which > cross over certain wires so that the right signals are always being > sent; it's possible your old cable had these connections but your > current cable doesn't have them. If you can find the old cable, you > could put it back in and see if that fixes things? > > > 2009/9/8 Nathaniel S. Parsons : > > (Sorry if this is a double post, but I sent my original message without > > subscribing, and since this is an urgent problem, I thought I'd resend > after > > subscribing to bypass the moderator limbo zone) > > > > Hi all, > > > > I've asked my question on StackOverflow already, so rather than > copy-paste > > the question here, I'd like to redirect you there. > > > > Short version, I am no longer able to receive anything over RS-232 with > > RXTX, but other programs work fine. I'm definitely sending things, > because > > when I connect with a different program, all the responses to the > commands I > > sent via RXTX arrive all at once. > > > > Everything was fine in the spring, so what could have happened? Windows > > update? > > > > -Nate > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 18:57:58 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 20:57:58 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: I added a call to setRTS() but nothing changed in Serial Port Monitor, no matter what the argument was. Is this a bug, or did I call the wrong function? I tried to find the c code behind this function, and I think I found it in rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong to me. Am I looking at the right function or is the problem somewhere else? -Nate On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons wrote: > Thanks for the response. I'll try to get to the electronics store tomorrow > to get more serial cables, even if it isn't the problem. > > I am using a different serial cable than I was in the spring. It's actually > a Male/Female cable with a female-female adapter since the old cables aren't > around anymore. The hardware's manual says nothing except to use a "Straight > cable" but I figured that if it worked in HyperTerminal, it should work in > RXTX, right? > > Anyways, I've also noticed some things that are different between > HyperTerminal, RXTX, and a separate program I found that communicates with > the device (but doesn't do what I want, which is why I'm rolling my own > program) > > HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and > DTR indicators are green > Other program - not sure what settings it thinks it's using, but only SPM's > RTS indicator is green > RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators > are on. > > From Serial Port Monitor's help files (paraphrased): the indicators display > the state of the serial control lines > > RTS - Request To Send > CTS - Clear To Send > DTR - Data Terminal Ready > > Could this be related to the problem? > > -Nate > > > On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > >> OK, so: >> >> 1. It worked in spring but has stopped doing so and >> 2. The data all arrives at once when you start hyperterminal. >> >> Is it possible you're using a different serial cable to connect to the >> device, compared to the one you were using in spring? >> >> If so, the issue might be hardware flow control - that is, your device >> might be buffering data because it can't transmit it until your >> computer sets 'DTR' or 'RTS' or something like that. >> >> One way of bypassing hardware flow control is by using cables which >> cross over certain wires so that the right signals are always being >> sent; it's possible your old cable had these connections but your >> current cable doesn't have them. If you can find the old cable, you >> could put it back in and see if that fixes things? >> >> >> 2009/9/8 Nathaniel S. Parsons : >> > (Sorry if this is a double post, but I sent my original message without >> > subscribing, and since this is an urgent problem, I thought I'd resend >> after >> > subscribing to bypass the moderator limbo zone) >> > >> > Hi all, >> > >> > I've asked my question on StackOverflow already, so rather than >> copy-paste >> > the question here, I'd like to redirect you there. >> > >> > Short version, I am no longer able to receive anything over RS-232 with >> > RXTX, but other programs work fine. I'm definitely sending things, >> because >> > when I connect with a different program, all the responses to the >> commands I >> > sent via RXTX arrive all at once. >> > >> > Everything was fine in the spring, so what could have happened? Windows >> > update? >> > >> > -Nate >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Tue Sep 8 21:54:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 21:54:26 -0600 (MDT) Subject: [Rxtx] rxtx is moving to the clouds Message-ID: rxtx is moving onto a cloud server. You may notice short outages as things move around. So far the following is done. http://rxtx.qbang.org (will redirect rxtx.org there for 2.2) http://bugzilla.qbang.org (bugs) The mail-list is tomorrow night. CVS and FTP will be last. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 8 22:03:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 22:03:26 -0600 (MDT) Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: On Tue, 8 Sep 2009, Nathaniel S. Parsons wrote: > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? Hi Nathaniel, That depends upon what you are running. WinCE is for embedded windows. The Windows source is in src/termios.c (called from src/SerialImp.c). -- Trent Jarvi tjarvi at qbang.org From m.j.tandy at warwick.ac.uk Wed Sep 9 03:27:10 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 10:27:10 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> I had a similar problem a while ago - hardware that would work with Hyperterminal but not with Rxtx. I don't know if this is a bug in RxTx or not - I tried to find where in the RxTx source code those functions are actually implemented - I got as far as the ioctl function in termios.c, where the TIOCMSET case sets the MSR byte in the termios struct, but I can't figure out where that gets written to the dcb struct's fDtrControl dword. It could be a bug, or it could just be me missing something. In any case, at the time I had this problem I wasn't equipped to debug RxTx so instead I created a special cable to satisfy the hardware's flow control while leaving the data connection straight through. Here's how I connected it: At the female end of the cable (i.e. the hardware I was connecting to) I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. I connected the ground and data pins straight through - that is, pin 5 female end to pin 5 male end, pin 2 female end to pin 2 male end, pin 3 female end to pin 3 male end. Anyway, using that cable bypassed the hardware's flow control, and got RxTx working just as well as HyperTerminal - although I slowed down my communication to make sure I didn't encounter a situation where the flow control would have come into effect, as I had bypassed it! Hope that helps. 2009/9/9 Nathaniel S. Parsons : > I added a call to setRTS() but nothing changed in Serial Port Monitor, no > matter what the argument was. Is this a bug, or did I call the wrong > function? > > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? > > -Nate > > On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > wrote: >> >> Thanks for the response. I'll try to get to the electronics store tomorrow >> to get more serial cables, even if it isn't the problem. >> >> I am using a different serial cable than I was in the spring. It's >> actually a Male/Female cable with a female-female adapter since the old >> cables aren't around anymore. The hardware's manual says nothing except to >> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >> should work in RXTX, right? >> >> Anyways, I've also noticed some things that are different between >> HyperTerminal, RXTX, and a separate program I found that communicates with >> the device (but doesn't do what I want, which is why I'm rolling my own >> program) >> >> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >> DTR indicators are green >> Other program - not sure what settings it thinks it's using, but only >> SPM's RTS indicator is green >> RXTX - no matter what flow control I set, only SPM's CTS and DTR >> indicators are on. >> >> From Serial Port Monitor's help files (paraphrased): the indicators >> display the state of the serial control lines >> >> RTS - Request To Send >> CTS - Clear To Send >> DTR - Data Terminal Ready >> >> Could this be related to the problem? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> wrote: >>> >>> OK, so: >>> >>> 1. It worked in spring but has stopped doing so and >>> 2. The data all arrives at once when you start hyperterminal. >>> >>> Is it possible you're using a different serial cable to connect to the >>> device, compared to the one you were using in spring? >>> >>> If so, the issue might be hardware flow control - that is, your device >>> might be buffering data because it can't transmit it until your >>> computer sets 'DTR' or 'RTS' or something like that. >>> >>> One way of bypassing hardware flow control is by using cables which >>> cross over certain wires so that the right signals are always being >>> sent; it's possible your old cable had these connections but your >>> current cable doesn't have them. If you can find the old cable, you >>> could put it back in and see if that fixes things? >>> >>> >>> 2009/9/8 Nathaniel S. Parsons : >>> > (Sorry if this is a double post, but I sent my original message without >>> > subscribing, and since this is an urgent problem, I thought I'd resend >>> > after >>> > subscribing to bypass the moderator limbo zone) >>> > >>> > Hi all, >>> > >>> > I've asked my question on StackOverflow already, so rather than >>> > copy-paste >>> > the question here, I'd like to redirect you there. >>> > >>> > Short version, I am no longer able to receive anything over RS-232 with >>> > RXTX, but other programs work fine. I'm definitely sending things, >>> > because >>> > when I connect with a different program, all the responses to the >>> > commands I >>> > sent via RXTX arrive all at once. >>> > >>> > Everything was fine in the spring, so what could have happened? Windows >>> > update? >>> > >>> > -Nate >>> > >>> > _______________________________________________ >>> > Rxtx mailing list >>> > Rxtx at qbang.org >>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>> > >>> > >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Wed Sep 9 03:54:45 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 12:54:45 +0300 Subject: [Rxtx] Xcode 3.x project available in CVS Message-ID: Hi everyone, I've just committed Apple Xcode 3.x (preferably 3.2) compatible project to CVS. The project can be used to develop and build Mac OS X 10.5+ compatible Universal Binary JNI library and RXTXcomm.jar. It's does not have dependencies to existing Autotools based build scripts - only standard Xcode installation is required. The older Xcode 2.x project is still there, but please note that it's not compatible with newer Xcode versions due to its dependency to deprecated Jam build system. The new project is available in rxtx-devel/MACOSX_IDE/Xcode3 How to get the source code from CVS: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Latest Xcode can be downloaded from Apple: http://developer.apple.com/technology/xcode.html -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 05:07:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 14:07:05 +0300 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: Nathaniel, I agree with Michael that your issue is probably with incorrect hardware flow control (RTS/CTS + possibly DTR/DSR). With RXTX you can do things manually, automatically or by mixing both ways. RXTX is "low-level" enough to let developer make those decisions. Which is proper. Automatic hardware flow-control: If you want to do automatic RTS/CTS flow control in both directions (from and to PC) you must set: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Note that you must combine flow control flags with bitwise OR ( ' | ' ) Manual: If you want to bypass all flow controls signals, or handle them manually you must set: setFlowControlMode( SerialPort.FLOWCONTROL_NONE ); In manual mode, you must manually handle controlling signals from PC and reading flow control signals from by the device: RTS - Request To Send -- setRTS() method can used to set this CTS - Clear To Send -- isCTS() method can be used to read this For example, it is entirely possible to manually implement normal RTS/ CTS flow control with RXTX without relying on low-level automatic implementation. Mixed: You can also configure serial port to handle RTS/CTS automatically in only one direction, then you must set one of: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN ); or setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_OUT ); Then you can either ignore or implement manually the flow control scheme in the other direction. DTR and DSR: These are not officially flow control signals, but might affect external devices (disable, standby etc.). Use and meaning of these depends on the device. DTR - Data Terminal Ready -- setDTR() method DSR - Data Set Ready -- setDSR() method CTS/RTS standards: Please note that there are two standard ways RTS/CTS flow control is done (depends on the device): asymmetric (RS-232) symmetric (RS-232-E / TIA-232-E) For more info see: http://en.wikipedia.org/wiki/RS232#RTS.2FCTS_handshaking Some devices may even use RTS/CTS to some other non-standard purpose. With those devices, enabling automatic RTS/CTS could cause very strange behaviour as they clearly require manual control of CTS/RTS. ---- As far as I know, RXTX properly controls all these signals all the way to actual RS232 pins - unless there is a new platform incompatibility bug that I'm not aware of;) Mostly it's just wrong combination and/or usage of these additional signals that cause problems receiving or sending. And the only solution is to really *know* how your device wants these signals handled - and then code your RXTX application accordingly. Creating non-standard cable is not the right solution in my opinion. Unfortunately some applications (like HyperTerminal for example) might hit more or less accidentally to the right combination of RTS/CTS/DTR/ DSR usage and make RXTX look bad in comparison. While all RXTX does by default is - well - nothing. It gives full control the developer. -- I > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port >> Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I >> found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't >> look wrong >> to me. Am I looking at the right function or is the problem >> somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > > >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store >>> tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since >>> the old >>> cables aren't around anymore. The hardware's manual says nothing >>> except to >>> use a "Straight cable" but I figured that if it worked in >>> HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that >>> communicates with >>> the device (but doesn't do what I want, which is why I'm rolling >>> my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's >>> RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but >>> only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> > >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect >>>> to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your >>>> device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>>> (Sorry if this is a double post, but I sent my original message >>>>> without >>>>> subscribing, and since this is an urgent problem, I thought I'd >>>>> resend >>>>> after >>>>> subscribing to bypass the moderator limbo zone) >>>>> >>>>> Hi all, >>>>> >>>>> I've asked my question on StackOverflow already, so rather than >>>>> copy-paste >>>>> the question here, I'd like to redirect you there. >>>>> >>>>> Short version, I am no longer able to receive anything over >>>>> RS-232 with >>>>> RXTX, but other programs work fine. I'm definitely sending things, >>>>> because >>>>> when I connect with a different program, all the responses to the >>>>> commands I >>>>> sent via RXTX arrive all at once. >>>>> >>>>> Everything was fine in the spring, so what could have happened? >>>>> Windows >>>>> update? >>>>> >>>>> -Nate >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 06:11:11 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 15:11:11 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings Message-ID: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Hi, Summary: Patch includes multiple minor code quality improvements and also fixes one possible null pointer segfault on Mac. After this patch, compilation on Mac OS X is error/warning free even with gcc -Wall setting. I'll submit more code quality patches later that focus more on linux/ win/java. Fixes: Code quality: - First level parentheses around assignment used as while-loop truth value - Some printf formats not a string literals and including no format arguments Invalid null pointer usage: - Mac: IOMasterPort was called with (int)NULL which does not always resolve to segfault safe value. Corrected to use MACH_PORT_NULL instead. Patch: The patch is against CVS head (@2009/09/09). Attached patch file is in 'cvs diff -up' format. I'll commit this patch to the CVS later this week if there are no objections. Feel free to comment. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090909.patch Type: application/octet-stream Size: 1966 bytes Desc: not available URL: From m.j.tandy at warwick.ac.uk Wed Sep 9 06:57:55 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 13:57:55 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> OK, I just ran a test with my copy of RxTx and the following program: import gnu.io.*; public class SerialTest { public static void main(String[] args) { try { CommPortIdentifier portid = CommPortIdentifier.getPortIdentifier("COM9"); SerialPort serialPort = (SerialPort)portid.open("Serial port DTR/RTS test", 1000); serialPort.setSerialPortParams(4800, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.disableReceiveTimeout(); for (int i=0 ; i<60 ; i++) { serialPort.setDTR(true); serialPort.setRTS(true); Thread.sleep(1000); serialPort.setDTR(false); serialPort.setRTS(false); Thread.sleep(1000); } } catch (Exception e) { e.printStackTrace(); System.exit(1); } System.exit(0); } } I'm using a USB-serial converter (Prolific PL-2303) and I used a multimeter to check that my DTR and RTS pins were both toggling, and they were - between +7 and -6.4 volts. In other words, on the computer I'm using at the moment, with the version of RxTx I'm using at the moment, setDTR and setRTS both seem to work fine. I don't know if it's worth it for you to perform the same test. I gather there are several different configurations for hardware flow control, (DTR/DSR handshaking as well as RTS/CTS handshaking, handshaking for half-duplex operation, and similar) so the cable that worked for me might still be worth a try. 2009/9/9 Michael Tandy : > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong >> to me. Am I looking at the right function or is the problem somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since the old >>> cables aren't around anymore. The hardware's manual says nothing except to >>> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that communicates with >>> the device (but doesn't do what I want, which is why I'm rolling my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>> > (Sorry if this is a double post, but I sent my original message without >>>> > subscribing, and since this is an urgent problem, I thought I'd resend >>>> > after >>>> > subscribing to bypass the moderator limbo zone) >>>> > >>>> > Hi all, >>>> > >>>> > I've asked my question on StackOverflow already, so rather than >>>> > copy-paste >>>> > the question here, I'd like to redirect you there. >>>> > >>>> > Short version, I am no longer able to receive anything over RS-232 with >>>> > RXTX, but other programs work fine. I'm definitely sending things, >>>> > because >>>> > when I connect with a different program, all the responses to the >>>> > commands I >>>> > sent via RXTX arrive all at once. >>>> > >>>> > Everything was fine in the spring, so what could have happened? Windows >>>> > update? >>>> > >>>> > -Nate >>>> > >>>> > _______________________________________________ >>>> > Rxtx mailing list >>>> > Rxtx at qbang.org >>>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>>> > >>>> > >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > From david at attglobal.net Wed Sep 9 09:17:27 2009 From: david at attglobal.net (David Schmidt) Date: Wed, 09 Sep 2009 11:17:27 -0400 Subject: [Rxtx] 2.2 Release plans Message-ID: <4AA7C707.5060802@attglobal.net> I'm holding off releasing an update to my project (adtpro.sourceforge.net) to support OSX Snow Leopard because I'd like to ship an "official" build of rxtx 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for toggling a port off). CVS is looking great on OSX - thanks to all who have been hard at work on that. I wish there were just one more update - Pre3? :-) My question... If I wanted to make a release in, say, a week... would it pay to wait for rxtx, or should I plan to build and ship a local build of 2.2 out of CVS myself? - David Schmidt From tjarvi at qbang.org Wed Sep 9 19:14:29 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:14:29 -0600 (MDT) Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: On Wed, 9 Sep 2009, Ilkka Myller wrote: > Hi, > > Summary: > > Patch includes multiple minor code quality improvements and also fixes one > possible null pointer segfault on Mac. > After this patch, compilation on Mac OS X is error/warning free even with gcc > -Wall setting. > I'll submit more code quality patches later that focus more on > linux/win/java. > > Fixes: > > Code quality: > - First level parentheses around assignment used as while-loop truth value > - Some printf formats not a string literals and including no format arguments > > Invalid null pointer usage: > - Mac: IOMasterPort was called with (int)NULL which does not always resolve > to segfault safe value. Corrected to use MACH_PORT_NULL instead. > > Patch: > > The patch is against CVS head (@2009/09/09). > Attached patch file is in 'cvs diff -up' format. > > I'll commit this patch to the CVS later this week if there are no objections. > Feel free to comment. > These ifdefs can go. If you like I can remove them when you are done. #ifdef DEBUG_MW mexErrMsgTxt( msg ); #else They are just printf like debug messages for use in an environment in which I could not get directly to stderr/stdout. I don't think anyone uses them anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Sep 9 19:17:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:17:43 -0600 (MDT) Subject: [Rxtx] 2.2 Release plans In-Reply-To: <4AA7C707.5060802@attglobal.net> References: <4AA7C707.5060802@attglobal.net> Message-ID: On Wed, 9 Sep 2009, David Schmidt wrote: > I'm holding off releasing an update to my project (adtpro.sourceforge.net) to > support OSX Snow Leopard because I'd like to ship an "official" build of rxtx > 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for > toggling a port off). CVS is looking great on OSX - thanks to all who have > been hard at work on that. I wish there were just one more update - Pre3? > :-) > > My question... If I wanted to make a release in, say, a week... would it pay > to wait for rxtx, or should I plan to build and ship a local build of 2.2 out > of CVS myself? > Hi David, I would suggest planning on shipping a local build in a 1 week timeframe. We could put another prerelease up but there are still fixes coming in. -- Trent Jarvi tjarvi at qbang.org From ilkka at myller.com Wed Sep 9 23:07:34 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:07:34 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: <04A41559-598C-4B6E-821A-DA90CB6228E7@myller.com> Patch (im-20090909.patch) has been committed to the CVS. Trent: I'll include DEBUG_MW cleanup to my next patch. > > On Wed, 9 Sep 2009, Ilkka Myller wrote: > >> Hi, >> >> Summary: >> >> Patch includes multiple minor code quality improvements and also >> fixes one possible null pointer segfault on Mac. >> After this patch, compilation on Mac OS X is error/warning free >> even with gcc -Wall setting. >> I'll submit more code quality patches later that focus more on >> linux/win/java. >> >> Fixes: >> >> Code quality: >> - First level parentheses around assignment used as while-loop >> truth value >> - Some printf formats not a string literals and including no format >> arguments >> >> Invalid null pointer usage: >> - Mac: IOMasterPort was called with (int)NULL which does not always >> resolve to segfault safe value. Corrected to use MACH_PORT_NULL >> instead. >> >> Patch: >> >> The patch is against CVS head (@2009/09/09). >> Attached patch file is in 'cvs diff -up' format. >> >> I'll commit this patch to the CVS later this week if there are no >> objections. >> Feel free to comment. >> > > These ifdefs can go. If you like I can remove them when you are done. > > #ifdef DEBUG_MW > mexErrMsgTxt( msg ); > #else > > They are just printf like debug messages for use in an environment > in which I could not get directly to stderr/stdout. I don't think > anyone uses them anymore. > > -- > Trent Jarvi > tjarvi at qbang.org From ilkka at myller.com Wed Sep 9 23:35:13 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:35:13 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= Message-ID: Hi, Summary: Patch fixes compiling on Linux distributions/kernels that dont ship with linux/utsrelease.h header and therefore have no UTS_RELEASE defined. Usually this applies only to newer distributions and/or kernels - for example Ubuntu 9.04. Fixes: The UTS_RELEASE vs uname checking in initialization functions is now done only in debug build and only when UTS_RELEASE is actually defined. Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910.patch Type: application/octet-stream Size: 9542 bytes Desc: not available URL: From ilkka at myller.com Thu Sep 10 06:43:02 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 15:43:02 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= In-Reply-To: References: Message-ID: Patch has been committed to CVS. > Hi, > > Summary: > > Patch fixes compiling on Linux distributions/kernels that dont ship > with linux/utsrelease.h header and therefore have no UTS_RELEASE > defined. > Usually this applies only to newer distributions and/or kernels - > for example Ubuntu 9.04. > > Fixes: > > The UTS_RELEASE vs uname checking in initialization functions is now > done only in debug build and only when UTS_RELEASE is actually > defined. > > Patch: > > The patch is against CVS head (@2009/09/10). > Attached patch file is in 'cvs diff -up' format. > > > Thanks, > > -- > I > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Thu Sep 10 09:08:01 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 18:08:01 +0300 Subject: [Rxtx] [Patch] Remove unused MathWorks MATLAB DEBUG_MW ifdefs Message-ID: <6DB57DB1-A47E-4435-9CD6-212B671A2849@myller.com> Summary: Patch removes unused MathWorks MATLAB timing debug ifdefs (DEBUG_MW). This is a request from Trent. Fixes: - Removes DEBUG_MW definitions - Removes unused mex....() function definitions - Corrects DEBUG_TIMING to work properly without mexPrintf (with Mac OS X specific format string fixes included) - Removes unused/duplicate timeval struct and DEBUG_TIMING definitions from SerialImp.c and SerialImp.h - Corrects fprintf call in SerialImp.cpp Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910b.patch Type: application/octet-stream Size: 9841 bytes Desc: not available URL: From Kapil_Gupta at hcl.in Thu Sep 10 10:25:29 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 10 Sep 2009 21:55:29 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, I am getting some problem with RXTX on macintosh (reading some data from the device attached to the usb port through usb to serial mechanism). I used the RXTX 2.1.7 then I got PortInUseException but after using 2.2pre it worked fine. But it works only for the first time, it hangs in the second time while opening the port. Please find the attached code. This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Thu Sep 10 13:00:14 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 22:00:14 +0300 Subject: [Rxtx] [Patch] Implement return value checking to file I/O calls Message-ID: Summary: The return value of some functions should always be used. For example, it is dangerous to not check the return value of a write(), read(), open(), fscanf() calls. This patch fixes such occurences in RXTX code. For example: unchecked read() call could result in later - and often seemingly unrelated - segfault due to undefined read buffer contents. After this patch the Linux build process is error/warning free even with gcc -Wall -Werror. Fixes: - Implemented return value checking to file I/O calls in SerialImp.c:fhs_lock(), uucp_lock() and is_device_locked() functions. - Added error recovery for fuserImp.c fscanf() calls. Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910c.patch Type: application/octet-stream Size: 3370 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Thu Sep 10 13:08:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 22:08:05 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> Hi Kapil, I believe this issue has been fixed in CVS version, but still exists in 2.2pre2 available from RXTX wiki. For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html As you've seen from the recent patches announced on this list, we are working very hard to make a new 2.2pre(?) release available. Meanwhile, you can compile your own RXTX binaries from CVS source. On Mac it should be exceptionally easy with new Xcode 3.x project files. Thank you for your patience, -- I > > I am getting some problem with RXTX on macintosh (reading some data > from the device attached to the usb port through usb to serial > mechanism). I used the RXTX 2.1.7 then I got PortInUseException but > after using 2.2pre it worked fine. But it works only for the first > time, it hangs in the second time while opening the port. From ilkka at myller.com Fri Sep 11 04:07:22 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 13:07:22 +0300 Subject: [Rxtx] [Patch] Windows build improvements (MinGW32, MSVC and LCC) Message-ID: <81D06766-8D51-485A-B2A2-624C8EA690BA@myller.com> Summary: Fixes various compiler warnings with Windows builds. Removes unused code blocks from compilation. After this patch the Windows build process is error/warning free with MinGW32, MSVC and LCC compilers - even with -Wall enabled. Does not fix: Latest LCC compiler version still fails even after this patch due to compiler trap error. Trap error does not specify source code location - it fails outputting SerialImp.obj binary. Compiling SerialImp.c without binary output works. Could this be a bug in LCC? Tested with clean RXTX source, latest standard LCC installation and with both Windows Vista SP1 x86 and Windows XP SP3 x86. Patch: The patch is against CVS (@2009/09/11). Attached patch file is in 'cvs diff -up' format. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090911.patch Type: application/octet-stream Size: 6673 bytes Desc: not available URL: From Kapil_Gupta at hcl.in Fri Sep 11 08:21:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Fri, 11 Sep 2009 19:51:24 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Ilkka, I tried getting the source code from the CVS but we could not able to do so, the CVS was not responding. Then we downloaded the 2.2 pre2 code and made the changes that are described in http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html but the problem didn't change. First time the device responds well and the second time it hangs. Did you see the code that we have sent to you, so that you can suggest if we are doing something wrong in our code. Again attaching if you have deleted that. Please suggest (does the CVS code can help rather using the patch provided by you?). Thanks, Kapil -----Original Message----- From: Ilkka Myller [mailto:ilkka at myller.com] Sent: Friday, September 11, 2009 12:38 AM To: Kapil Gupta Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Hi Kapil, I believe this issue has been fixed in CVS version, but still exists in 2.2pre2 available from RXTX wiki. For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html As you've seen from the recent patches announced on this list, we are working very hard to make a new 2.2pre(?) release available. Meanwhile, you can compile your own RXTX binaries from CVS source. On Mac it should be exceptionally easy with new Xcode 3.x project files. Thank you for your patience, -- I > > I am getting some problem with RXTX on macintosh (reading some data > from the device attached to the usb port through usb to serial > mechanism). I used the RXTX 2.1.7 then I got PortInUseException but > after using 2.2pre it worked fine. But it works only for the first > time, it hangs in the second time while opening the port. DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Fri Sep 11 09:33:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 18:33:33 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Hi Kapil, For CVS: Instructions at the old rxtx website are incorrect. Trent updated them, but to a wrong server address "qgang.org" -- the correct server is "qbang.org". Please follow instructions from rxtx wiki: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code About testing your code: When I have time (maybe this weekend), I'll test your code using Mac OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. What USB serial port you are using with your Mac? Something with FTDI chip? or maybe Prolific? What adapter driver version you are using? Just asking, so I can test with the same configuration. Meanwhile I suggest you: - Make sure you have the latest USB Serial adapter drivers, so we can eliminate past issues with those. - Check that you are not having multiple copies of librxtxSerial.jnilib (possibly different versions) in your java library path (=trouble;) - Check for any USB Serial adaptors kernel extension error messages in system log after testing your software (use Console.app to browse logs) -- I Kapil Gupta kirjoitti 11.9.2009 kello 17.21: > Hi Ilkka, > > I tried getting the source code from the CVS but we could not able > to do so, the CVS was not responding. Then we downloaded the 2.2 > pre2 code and made the changes that are described in http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html > but the problem didn't change. First time the device responds well > and the second time it hangs. > > Did you see the code that we have sent to you, so that you can > suggest if we are doing something wrong in our code. Again attaching > if you have deleted that. Please suggest (does the CVS code can help > rather using the patch provided by you?). > > Thanks, > Kapil > > -----Original Message----- > From: Ilkka Myller [mailto:ilkka at myller.com] > Sent: Friday, September 11, 2009 12:38 AM > To: Kapil Gupta > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second > time port open > > Hi Kapil, > > I believe this issue has been fixed in CVS version, but still exists > in 2.2pre2 available from RXTX wiki. > > For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html > > As you've seen from the recent patches announced on this list, we are > working very hard to make a new 2.2pre(?) release available. > > Meanwhile, you can compile your own RXTX binaries from CVS source. On > Mac it should be exceptionally easy with new Xcode 3.x project files. > > > Thank you for your patience, > > > -- > I > > >> >> I am getting some problem with RXTX on macintosh (reading some data >> from the device attached to the usb port through usb to serial >> mechanism). I used the RXTX 2.1.7 then I got PortInUseException but >> after using 2.2pre it worked fine. But it works only for the first >> time, it hangs in the second time while opening the port. > > > DISCLAIMER: > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential > and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of this > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > ----------------------------------------------------------------------------------------------------------------------- > From ilkka at myller.com Fri Sep 11 11:51:13 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 20:51:13 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Message-ID: <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> Ok, I debugged your code on Mac using USB-RS232 adapter + loopback adapter. My findings: there are no issues with RXTX in your code -- there are issues with threading and synchronization. Primary issue: you essentially lock the JVM main thread to 100% CPU usage with infinite loop: while (!processCompleted) { ; } Now.. I'm going to give you a bad advice, mostly because you have bigger threading issues there.. but we must continue somehow: A quick remedy to previous is: while (!processCompleted) { Thread.yield(); } Thread yielding gives other threads atleast a chance to run (and to processCompleted boolean to actually update in main thread context). What happens next is that your main-thread is allowed to continue and proceeds to closeConnection() call it otherwise would never reach. After that, connection closes properly.. main() method continues to "System.out.println(result);" and proceeds to exit JVM.. .. except.. Secondary issue: Exit is one thing JVM cant do since you have left a Timer thread hanging without proper closing in getData() method. Cancel it (uncomment that line) - and your code completes main() to a clean JVM exit. So, my advice to you is to focus on fixing threading, timers and synchronization. Design those well and everything works. Multithreading, done well or not, will not usually confuse RXTX ... but your own code might not be so lucky. -- I > > When I have time (maybe this weekend), I'll test your code using Mac > OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. >> >> Did you see the code that we have sent to you, so that you can >> suggest if we are doing something wrong in our code. Again >> attaching if you have deleted that. Please suggest (does the CVS >> code can help rather using the patch provided by you?). -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 11 15:19:26 2009 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 11 Sep 2009 17:19:26 -0400 Subject: [Rxtx] Can't run my Netbeans/Java s/w on a MAC Message-ID: <4AAABEDE.7020508@howardz.com> An HTML attachment was scrubbed... URL: From ilkka at myller.com Fri Sep 11 15:41:10 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 12 Sep 2009 00:41:10 +0300 Subject: [Rxtx] Can't run my Netbeans/Java s/w on a MAC In-Reply-To: <4AAABEDE.7020508@howardz.com> References: <4AAABEDE.7020508@howardz.com> Message-ID: <35D4BD73-B8CC-4DEE-A846-8858C9C9EBC7@myller.com> Hi, The bug that causes the segfault (invalid memory access) has been fixed (in CVS): http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html Next prerelease is coming (soon I hope), but the the 2.2pre2 fails when reopening the serial port on Mac OS X. -- I > > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] Jar > version = RXTX-2.2pre1 > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] native > lib Version = RXTX-2.2pre2 > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] Invalid > memory access of location 0x12b5e3938 rip=0x12955012f > 9/6/09 3:46:00 PM ReportCrash[6164] Saved crash report for java > [6162] version 13.0.0 (13.0.0) to /Users/myles/Library/Logs/ > DiagnosticReports/java_2009-09-06-154600_myles-PowerBook-PP-108.crash -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Fri Sep 11 20:15:31 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 11 Sep 2009 20:15:31 -0600 (MDT) Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Message-ID: On Fri, 11 Sep 2009, Ilkka Myller wrote: > Hi Kapil, > > For CVS: > > Instructions at the old rxtx website are incorrect. Trent updated them, but > to a wrong server address "qgang.org" -- the correct server is "qbang.org". > Please follow instructions from rxtx wiki: > > http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code The old website has been corrected. -- Trent Jarvi tjarvi at qbang.org From dvd at newfoundmarket.com Sat Sep 12 11:49:48 2009 From: dvd at newfoundmarket.com (DVD) Date: Sat, 12 Sep 2009 13:49:48 -0400 Subject: [Rxtx] RXTX on linux hang Message-ID: <4AABDF3C.2040908@newfoundmarket.com> Hello: I just did a fresh install of RXTZ on both Ubuntu and centos, Java version 6, update 12 I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with the Usage example from your website Two way communcation with the serial port I used the computer's serial port /dev/ttyS0, with UART 16550A the program simply hang. The port was opened and both input/output streamed were opened but the writing/reading are not working. Any help would be appreciated. I tried this program on windows and it worked fine. Thanks From ilkka at myller.com Sat Sep 12 15:31:26 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sun, 13 Sep 2009 00:31:26 +0300 Subject: [Rxtx] RXTX on linux hang In-Reply-To: <4AABDF3C.2040908@newfoundmarket.com> References: <4AABDF3C.2040908@newfoundmarket.com> Message-ID: Hi, It's very hard to say what could be wrong without more details. Can you tell me more about your Linux setup: - Output of: uname -a - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your test code running) - Output of: cat /proc/tty/driver/serial - Are you you testing with root privileges - What kind of device you are communicating with (or just a loopback dongle)? - Does your device expect some specific flow control and/or specific state of DTR/DSR signals? - Have you tried configuring those flow controls and other RS232 signals in your test code? Did they work? - Do other simple terminal programs work (easiest to try: screen /dev/ ttyS0 )? - What is the CPU usage (use 'top' or some other process monitor your like) of your test software when it "hangs"? I can try to duplicate your issue on Ubuntu 9.04 (both x86 and x86_64), Centos 5 (x86) and Debian 5.0 (x86). I'd prefer to test with the same kind of system you have.. Thanks, -- I > > I just did a fresh install of RXTZ on both Ubuntu and centos, Java > version 6, update 12 > I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with > the Usage example from > your website > > Two way communcation with the serial port > > > I used the computer's serial port /dev/ttyS0, with UART 16550A > > the program simply hang. The port was opened and both input/output > streamed were opened > but the writing/reading are not working. > > Any help would be appreciated. I tried this program on windows and > it worked fine. From dvd at newfoundmarket.com Sat Sep 12 21:20:14 2009 From: dvd at newfoundmarket.com (DVD) Date: Sat, 12 Sep 2009 23:20:14 -0400 Subject: [Rxtx] RXTX on linux hang In-Reply-To: References: <4AABDF3C.2040908@newfoundmarket.com> Message-ID: <4AAC64EE.7050904@newfoundmarket.com> Thank you very much for the steps. It is pin out problem. Again, Thanks. Ilkka Myller wrote: > Hi, > > It's very hard to say what could be wrong without more details. > Can you tell me more about your Linux setup: > > - Output of: uname -a > - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your > test code running) > - Output of: cat /proc/tty/driver/serial > - Are you you testing with root privileges > - What kind of device you are communicating with (or just a loopback > dongle)? > - Does your device expect some specific flow control and/or specific > state of DTR/DSR signals? > - Have you tried configuring those flow controls and other RS232 > signals in your test code? Did they work? > - Do other simple terminal programs work (easiest to try: screen > /dev/ttyS0 )? > - What is the CPU usage (use 'top' or some other process monitor your > like) of your test software when it "hangs"? > > > I can try to duplicate your issue on Ubuntu 9.04 (both x86 and > x86_64), Centos 5 (x86) and Debian 5.0 (x86). > I'd prefer to test with the same kind of system you have.. > > > Thanks, > > -- > I > > >> >> I just did a fresh install of RXTZ on both Ubuntu and centos, Java >> version 6, update 12 >> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with >> the Usage example from >> your website >> >> Two way communcation with the serial port >> >> >> >> I used the computer's serial port /dev/ttyS0, with UART 16550A >> >> the program simply hang. The port was opened and both input/output >> streamed were opened >> but the writing/reading are not working. >> >> Any help would be appreciated. I tried this program on windows and >> it worked fine. > From tjarvi at qbang.org Sun Sep 13 12:06:33 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Sep 2009 12:06:33 -0600 (MDT) Subject: [Rxtx] RXTX on linux hang In-Reply-To: <4AAC64EE.7050904@newfoundmarket.com> References: <4AABDF3C.2040908@newfoundmarket.com> <4AAC64EE.7050904@newfoundmarket.com> Message-ID: Hi, Would it be possible to get a short paragraph from you describing the pinout problem and how you discovered it? We can add that to the wiki to help others get past the problem faster next time. On Sat, 12 Sep 2009, DVD wrote: > Thank you very much for the steps. It is pin out problem. > Again, Thanks. > > Ilkka Myller wrote: >> Hi, >> >> It's very hard to say what could be wrong without more details. >> Can you tell me more about your Linux setup: >> >> - Output of: uname -a >> - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your test >> code running) >> - Output of: cat /proc/tty/driver/serial >> - Are you you testing with root privileges >> - What kind of device you are communicating with (or just a loopback >> dongle)? >> - Does your device expect some specific flow control and/or specific state >> of DTR/DSR signals? >> - Have you tried configuring those flow controls and other RS232 signals in >> your test code? Did they work? >> - Do other simple terminal programs work (easiest to try: screen /dev/ttyS0 >> )? >> - What is the CPU usage (use 'top' or some other process monitor your like) >> of your test software when it "hangs"? >> >> >> I can try to duplicate your issue on Ubuntu 9.04 (both x86 and x86_64), >> Centos 5 (x86) and Debian 5.0 (x86). >> I'd prefer to test with the same kind of system you have.. >> >> >> Thanks, >> >> -- >> I >> >> >>> >>> I just did a fresh install of RXTZ on both Ubuntu and centos, Java version >>> 6, update 12 >>> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with the >>> Usage example from >>> your website >>> >>> Two way communcation with the serial port >>> >>> >>> I used the computer's serial port /dev/ttyS0, with UART 16550A >>> >>> the program simply hang. The port was opened and both input/output >>> streamed were opened >>> but the writing/reading are not working. >>> >>> Any help would be appreciated. I tried this program on windows and it >>> worked fine. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dvd at newfoundmarket.com Sun Sep 13 19:18:08 2009 From: dvd at newfoundmarket.com (DVD) Date: Sun, 13 Sep 2009 21:18:08 -0400 Subject: [Rxtx] RXTX on linux hang In-Reply-To: References: <4AABDF3C.2040908@newfoundmarket.com> <4AAC64EE.7050904@newfoundmarket.com> Message-ID: <4AAD99D0.3030206@newfoundmarket.com> Hello, It was a human mistake during wiring and was discovered after staring at it for a while :-). Nothing technical worth mentioning. Thanks Trent Jarvi wrote: > > Hi, > > Would it be possible to get a short paragraph from you describing the > pinout problem and how you discovered it? We can add that to the wiki > to help others get past the problem faster next time. > > On Sat, 12 Sep 2009, DVD wrote: > >> Thank you very much for the steps. It is pin out problem. >> Again, Thanks. >> >> Ilkka Myller wrote: >>> Hi, >>> >>> It's very hard to say what could be wrong without more details. >>> Can you tell me more about your Linux setup: >>> >>> - Output of: uname -a >>> - Output of: stty -a -F /dev/ttyS0 (if possible: with and without >>> your test code running) >>> - Output of: cat /proc/tty/driver/serial >>> - Are you you testing with root privileges >>> - What kind of device you are communicating with (or just a loopback >>> dongle)? >>> - Does your device expect some specific flow control and/or specific >>> state of DTR/DSR signals? >>> - Have you tried configuring those flow controls and other RS232 >>> signals in your test code? Did they work? >>> - Do other simple terminal programs work (easiest to try: screen >>> /dev/ttyS0 )? >>> - What is the CPU usage (use 'top' or some other process monitor >>> your like) of your test software when it "hangs"? >>> >>> >>> I can try to duplicate your issue on Ubuntu 9.04 (both x86 and >>> x86_64), Centos 5 (x86) and Debian 5.0 (x86). >>> I'd prefer to test with the same kind of system you have.. >>> >>> >>> Thanks, >>> >>> -- >>> I >>> >>> >>>> >>>> I just did a fresh install of RXTZ on both Ubuntu and centos, Java >>>> version 6, update 12 >>>> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with >>>> the Usage example from >>>> your website >>>> >>>> Two way communcation with the serial port >>>> >>>> >>>> I used the computer's serial port /dev/ttyS0, with UART 16550A >>>> >>>> the program simply hang. The port was opened and both input/output >>>> streamed were opened >>>> but the writing/reading are not working. >>>> >>>> Any help would be appreciated. I tried this program on windows and >>>> it worked fine. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From Kapil_Gupta at hcl.in Mon Sep 14 08:37:23 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Mon, 14 Sep 2009 20:07:23 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B30A4F25D@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Ilkka, We have done that also, but no success. I am attaching the code, please check the updated code also. We are not using any FTDI/Prolific chip set. We are using TI chip set. We are having only one copy of JNI lib. No Error in console for kernel driver. Warm Regards, Kapil From: Ilkka Myller [mailto:ilkka at myller.com] Sent: Friday, September 11, 2009 11:21 PM To: Kapil Gupta Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Ok, I debugged your code on Mac using USB-RS232 adapter + loopback adapter. My findings: there are no issues with RXTX in your code -- there are issues with threading and synchronization. Primary issue: you essentially lock the JVM main thread to 100% CPU usage with infinite loop: while (!processCompleted) { ; } Now.. I'm going to give you a bad advice, mostly because you have bigger threading issues there.. but we must continue somehow: A quick remedy to previous is: while (!processCompleted) { Thread.yield(); } Thread yielding gives other threads atleast a chance to run (and to processCompleted boolean to actually update in main thread context). What happens next is that your main-thread is allowed to continue and proceeds to closeConnection() call it otherwise would never reach. After that, connection closes properly.. main() method continues to "System.out.println(result);" and proceeds to exit JVM.. .. except.. Secondary issue: Exit is one thing JVM cant do since you have left a Timer thread hanging without proper closing in getData() method. Cancel it (uncomment that line) - and your code completes main() to a clean JVM exit. So, my advice to you is to focus on fixing threading, timers and synchronization. Design those well and everything works. Multithreading, done well or not, will not usually confuse RXTX ... but your own code might not be so lucky. -- I When I have time (maybe this weekend), I'll test your code using Mac OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. Did you see the code that we have sent to you, so that you can suggest if we are doing something wrong in our code. Again attaching if you have deleted that. Please suggest (does the CVS code can help rather using the patch provided by you?). DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10005 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Mon Sep 14 17:03:55 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 15 Sep 2009 02:03:55 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B30A4F25D@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B30A4F25D@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <989B2FAA-5E5A-4F47-AF23-04CE1A6A20F7@myller.com> Kapil, You did not fix the primary issue. Your while() loop still blocks the main thread and the code is not working for the same reasons I stated before. .. but .. I created a demonstration code, which does not try to duplicate the behaviour of your code, but instead demonstrates few concepts: 1. Safe opening of the serial port with full error checking 2. Proper handling of text encoding using Reader/Writer. If your protocol handles plaintext, I recommend you use encoding capable streams. 3. Asynchronous multi-threaded receiving and transmitting (separate thread for each, with their own packet (=string, in this case) queues) 4. Handling serial port data-available events without blocking the event handler (=event only signals async. receiver) 5. Controlling access to serial port in multithreaded app using ReentrantLock (still allows embedded transmit->receive, as demonstrated) 6. Signaling thread from other thread with wait() -> notify() (demonstrated in serial event handling) The code does one simple thing: sends a US-ASCII encoded string to serial port with CR+LF and expects the same line to be received back. I used simple loopback adapter hardware to test this. Normally, doing just this simple task does not require such heavy multi-threading async. receiver/transmitter structures, but I created them to demonstrate various multi-threading concepts, and how they can be used with RXTX. The code is not perfect, it's still a quick hack to demonstrate few things. For example, it lacks proper error handling and propagation in async. receiver/transmitter. However, this code is "profiler clean". It's threads are mostly idle waiting other threads or actual events from RXTX. No thread is blocked in high CPU-% loops etc. when receiving or sending. This also scales nicely to run on multiple CPU's with modern JVM's. When implementing commercial protocol handlers this is how things should always be. Doing "while(someBoolean) {}" is generally not the correct method to sync things. -- I > Hi Ilkka, > > We have done that also, but no success. I am attaching the code, > please check the updated code also. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 11656 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail4ng at gmail.com Tue Sep 15 03:02:48 2009 From: mail4ng at gmail.com (Daniel Weinand) Date: Tue, 15 Sep 2009 11:02:48 +0200 Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby Message-ID: <4AAF5838.7080707@gmail.com> Hello, i'm using RXTX with a USB to Serial Adapter on Linux and Windows machines. Everything works great. but now i have a problem on a Vista machine with standby mode. after the machine wakes up i'll get an infinite error loop: Error 0x5 at ..\src\termios.c(2712): Access Denied Error 0x5 at ..\src\termios.c(517): Access Denied ... and so on. My Application runs as a windows service and so it tries to enumerate and connect to the port directly after it wakes up. but the Port is blocked until i restart the whole machine and everything starts from 0. i'm using rxtx 2.2pre2 is this a known problem and how to solve this? From stefan.frings at vodafone.com Tue Sep 15 09:08:04 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Tue, 15 Sep 2009 17:08:04 +0200 Subject: [Rxtx] Reloading C library after USB error Message-ID: Hello, I wrote a web application that uses rxtxcomm to communicate to USB devices through virtual serial ports (e.g. /dev/ttyUSB0) on Linux. When I unplug a device while the port is open and then plug it back, I cannot access it anymore. I need to kill -9 Tomcat and then restart it. I think that I need to re-load the C library. Another problem occurs when I plug in an USB device after my web application has started. In this case, the new device cannot be accessed through rxtxcomm. Again, I assume that I need to relaod the C library. I am not able to shut-down my web application after these two errors occur. Tomcat reports, that the shut-down failed. How can I reload the C library without hardly killing my running Tomcat? -------------- next part -------------- An HTML attachment was scrubbed... URL: From petter.real at gmail.com Tue Sep 15 14:32:29 2009 From: petter.real at gmail.com (Petter Rafael Villa Real) Date: Tue, 15 Sep 2009 17:32:29 -0300 Subject: [Rxtx] RXTX on Ubuntu 9.04 with lock in /var/lock/LCK..ttyS0. Message-ID: Hi, I always used the RXTX to read/write the serial successfully on Windows. But now I need to use Linux Ubuntu 9.04, I changed to COM1, with on Windows, to /dev/ttyS0, the reading starts on the terminal but the RXTX will warn that you must release the lock of the serial. In the RXTX documentation is indicated add uucd User groups and / or lock to resolve this problem, but in Ubuntu do not have this group. Does anyone have experience with Ubuntu to help me? P.S.: sorry for my bad english. Thank you. -- -- --------------------------------------------------------------------- Petter R. Villa Real Silva -- Desenvolvedor Web Viamais Desenvolvimento Web Powered by Java/Oracle PHP/MySQL Web Alocation e Hosting - PHP/JSP --------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at attglobal.net Tue Sep 15 19:36:38 2009 From: david at attglobal.net (David Schmidt) Date: Tue, 15 Sep 2009 21:36:38 -0400 Subject: [Rxtx] 2.2 Release plans In-Reply-To: References: <4AA7C707.5060802@attglobal.net> Message-ID: <4AB04126.5070002@attglobal.net> Trent Jarvi wrote: > On Wed, 9 Sep 2009, David Schmidt wrote: > >> I'm holding off releasing an update to my project >> (adtpro.sourceforge.net) to support OSX Snow Leopard because I'd like >> to ship an "official" build of rxtx 2.2. (I wouldn't mind shipping >> 2.2Pre2, but it lacks a critical fix for toggling a port off). CVS is >> looking great on OSX - thanks to all who have been hard at work on >> that. I wish there were just one more update - Pre3? :-) >> >> My question... If I wanted to make a release in, say, a week... would >> it pay to wait for rxtx, or should I plan to build and ship a local >> build of 2.2 out of CVS myself? >> > > Hi David, > > I would suggest planning on shipping a local build in a 1 week > timeframe. We could put another prerelease up but there are still fixes > coming in. Thanks for the encouragement, guys. I'm having a little less luck now - building for OSX on an Intel box runs on a PPC box, but not on Intel... weird. I guess I'll wait a bit more. :-) - David From david at attglobal.net Tue Sep 15 19:51:28 2009 From: david at attglobal.net (David Schmidt) Date: Tue, 15 Sep 2009 21:51:28 -0400 Subject: [Rxtx] FTDI chipset speed - much slower? Message-ID: <4AB044A0.10509@attglobal.net> I am finding that my app is behaving really slowly when I'm connecting with a FTDI chipset equipped USB-serial adapter. I'm finding my app to be "fast" when I use native UART ports, Prolific or Keyspan USB adapters. But my FTDI adapters are remarkably, astonishingly slower when sending data (in my case, this means moving data from the DE-9 to the USB end) than any other method. I mean it is maybe 1/5 the "normal" speed I see from every other method. CPU remains calm on the USB (i.e. Mac or PC) end of the adapter. It's just really slow. Data moving in the other direction seems to run at full speed. I'm suspecting I'm doing something wrong along the way that is reacting badly with this chipset. My initial, lazy question, before exposing my code to the harsh light of day: is there anything obvious I might be doing wrong to this chipset to make it run so slowly? Has anyone else run into the same problem? - David From tjarvi at qbang.org Tue Sep 15 20:03:51 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 15 Sep 2009 20:03:51 -0600 (MDT) Subject: [Rxtx] FTDI chipset speed - much slower? In-Reply-To: <4AB044A0.10509@attglobal.net> References: <4AB044A0.10509@attglobal.net> Message-ID: On Tue, 15 Sep 2009, David Schmidt wrote: > I am finding that my app is behaving really slowly when I'm connecting > with a FTDI chipset equipped USB-serial adapter. I'm finding my app to be > "fast" when I use native UART ports, Prolific or Keyspan USB adapters. > But my FTDI adapters are remarkably, astonishingly slower when sending > data (in my case, this means moving data from the DE-9 to the USB end) > than any other method. I mean it is maybe 1/5 the "normal" speed I see > from every other method. CPU remains calm on the USB (i.e. Mac or PC) end > of the adapter. It's just really slow. Data moving in the other > direction seems to run at full speed. > > I'm suspecting I'm doing something wrong along the way that is reacting > badly with this chipset. My initial, lazy question, before exposing my > code to the harsh light of day: is there anything obvious I might be doing > wrong to this chipset to make it run so slowly? Has anyone else run into > the same problem? > Given that rxtx does not treat usb special, it may be something to do with the nature of USB serial dongles. One suspicion I've had is that the event loop is competing for bandwidth by trying to check the UART status which is on the other side of the USB line. 1/5th is fairly significant. This is just writing/reading? How large are the transfers? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 15 20:07:12 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 15 Sep 2009 20:07:12 -0600 (MDT) Subject: [Rxtx] Reloading C library after USB error In-Reply-To: References: Message-ID: On Tue, 15 Sep 2009, Frings, Stefan, VF-DE wrote: > Hello, > ? > I wrote a web application that uses rxtxcomm to communicate to USB > devices through virtual serial ports (e.g. /dev/ttyUSB0) on Linux. > ? > When I unplug a device while the port is open and then plug it back, I > cannot access it anymore. I need to kill -9 Tomcat and then restart it. I > think that?I need to re-load the C library. > ? > Another problem occurs when I plug in an USB device after my web > application has started. In this case, the new device cannot be accessed > through rxtxcomm. Again, I assume that I need to relaod the C library. > ? > I am not able to shut-down my web application after these two errors > occur.? Tomcat reports, that the shut-down failed. > ? > How can I reload the C library without hardly killing my running Tomcat? > > I don't think the native library needs to shut down but the code does not expect the file descriptor to go invalid. Duct taping the USB dongle isnt always an option but thats how rxtx is currently coded. read/write and the event loop could all fail at any time and need to shut down the port. This code is not in place. We don't get USB events through the API so it has to be done by checking errors. The library also needs the ability to rescan the available ports. When it was written, you had to shut down the computer to remove a serial port so rescanning wasnt a concern. If those two fixes are made, you will be able to exit tomcat gracefully. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 15 20:08:54 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 15 Sep 2009 20:08:54 -0600 (MDT) Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby In-Reply-To: <4AAF5838.7080707@gmail.com> References: <4AAF5838.7080707@gmail.com> Message-ID: On Tue, 15 Sep 2009, Daniel Weinand wrote: > Hello, > > i'm using RXTX with a USB to Serial Adapter on Linux and Windows machines. > Everything works great. > but now i have a problem on a Vista machine with standby mode. after the > machine wakes up i'll get an infinite error loop: > > > Error 0x5 at ..\src\termios.c(2712): Access Denied > Error 0x5 at ..\src\termios.c(517): Access Denied > ... > > and so on. > > My Application runs as a windows service and so it tries to enumerate and > connect to the port directly > after it wakes up. but the Port is blocked until i restart the whole > machine and everything starts from 0. > > i'm using rxtx 2.2pre2 > > is this a known problem and how to solve this? It is a known problem. The kernel driver isnt restoring the fd. See the previous post for what is required prior to being able to handle it in your code. -- Trent Jarvi tjarvi at qbang.org From nsp25 at cornell.edu Tue Sep 15 20:50:11 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 15 Sep 2009 22:50:11 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> Message-ID: Thank you very much Ikka and Mike. Sorry I didn't get back sooner, but your emails got buried in my inbox, and I didn't see them until yesterday, or get to try it out until today. The following body of the connect method worked (same serial cable): SerialPort port = (SerialPort) CommPortIdentifier.getPortIdentifier("COM1").open("", 1000); port.setSerialPortParams(baud, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); // Never tried this before, it was just one or the other port.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT); port.setRTS(true); // Seems to work when flow control is set right port.setDTR(false); // Just in case port.disableReceiveTimeout(); However, I noticed what could be a bug in RXTX for Windows XP. While running PortMon, I discovered what could be problems in the (attached) log file, namely INVALID_PARAMETER return codes for IOCTL_SERIAL_CLR_RTS happens, I believe) and twice for IOCTL_SERIAL_SET_RTS. The log is nearly identical each time I connect, with the same failures. What's the easiest way I can run RXTX in debug mode? I have visual studio 2008, if that helps. If anyone wants to help me track this (new?) bug down, I can provide whatever computer information you ask for. -Nate On Wed, Sep 9, 2009 at 8:57 AM, Michael Tandy wrote: > OK, I just ran a test with my copy of RxTx and the following program: > > import gnu.io.*; > public class SerialTest { > public static void main(String[] args) { > > try { > CommPortIdentifier portid = > CommPortIdentifier.getPortIdentifier("COM9"); > SerialPort serialPort = (SerialPort)portid.open("Serial > port DTR/RTS test", 1000); > serialPort.setSerialPortParams(4800, > SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > serialPort.disableReceiveTimeout(); > for (int i=0 ; i<60 ; i++) { > serialPort.setDTR(true); > serialPort.setRTS(true); > Thread.sleep(1000); > serialPort.setDTR(false); > serialPort.setRTS(false); > Thread.sleep(1000); > } > } catch (Exception e) { > e.printStackTrace(); > System.exit(1); > } > System.exit(0); > } > } > > I'm using a USB-serial converter (Prolific PL-2303) and I used a > multimeter to check that my DTR and RTS pins were both toggling, and > they were - between +7 and -6.4 volts. > > In other words, on the computer I'm using at the moment, with the > version of RxTx I'm using at the moment, setDTR and setRTS both seem > to work fine. I don't know if it's worth it for you to perform the > same test. > > I gather there are several different configurations for hardware flow > control, (DTR/DSR handshaking as well as RTS/CTS handshaking, > handshaking for half-duplex operation, and similar) so the cable that > worked for me might still be worth a try. > > > 2009/9/9 Michael Tandy : > > I had a similar problem a while ago - hardware that would work with > > Hyperterminal but not with Rxtx. > > > > I don't know if this is a bug in RxTx or not - I tried to find where > > in the RxTx source code those functions are actually implemented - I > > got as far as the ioctl function in termios.c, where the TIOCMSET case > > sets the MSR byte in the termios struct, but I can't figure out where > > that gets written to the dcb struct's fDtrControl dword. It could be a > > bug, or it could just be me missing something. > > > > In any case, at the time I had this problem I wasn't equipped to debug > > RxTx so instead I created a special cable to satisfy the hardware's > > flow control while leaving the data connection straight through. > > Here's how I connected it: > > > > At the female end of the cable (i.e. the hardware I was connecting to) > > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > > I connected the ground and data pins straight through - that is, pin 5 > > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > > 3 female end to pin 3 male end. > > > > Anyway, using that cable bypassed the hardware's flow control, and got > > RxTx working just as well as HyperTerminal - although I slowed down my > > communication to make sure I didn't encounter a situation where the > > flow control would have come into effect, as I had bypassed it! > > > > Hope that helps. > > > > > > 2009/9/9 Nathaniel S. Parsons : > >> I added a call to setRTS() but nothing changed in Serial Port Monitor, > no > >> matter what the argument was. Is this a bug, or did I call the wrong > >> function? > >> > >> I tried to find the c code behind this function, and I think I found it > in > >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look > wrong > >> to me. Am I looking at the right function or is the problem somewhere > else? > >> > >> -Nate > >> > >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > > >> wrote: > >>> > >>> Thanks for the response. I'll try to get to the electronics store > tomorrow > >>> to get more serial cables, even if it isn't the problem. > >>> > >>> I am using a different serial cable than I was in the spring. It's > >>> actually a Male/Female cable with a female-female adapter since the old > >>> cables aren't around anymore. The hardware's manual says nothing except > to > >>> use a "Straight cable" but I figured that if it worked in > HyperTerminal, it > >>> should work in RXTX, right? > >>> > >>> Anyways, I've also noticed some things that are different between > >>> HyperTerminal, RXTX, and a separate program I found that communicates > with > >>> the device (but doesn't do what I want, which is why I'm rolling my own > >>> program) > >>> > >>> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS > and > >>> DTR indicators are green > >>> Other program - not sure what settings it thinks it's using, but only > >>> SPM's RTS indicator is green > >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR > >>> indicators are on. > >>> > >>> From Serial Port Monitor's help files (paraphrased): the indicators > >>> display the state of the serial control lines > >>> > >>> RTS - Request To Send > >>> CTS - Clear To Send > >>> DTR - Data Terminal Ready > >>> > >>> Could this be related to the problem? > >>> > >>> -Nate > >>> > >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy > > >>> wrote: > >>>> > >>>> OK, so: > >>>> > >>>> 1. It worked in spring but has stopped doing so and > >>>> 2. The data all arrives at once when you start hyperterminal. > >>>> > >>>> Is it possible you're using a different serial cable to connect to the > >>>> device, compared to the one you were using in spring? > >>>> > >>>> If so, the issue might be hardware flow control - that is, your device > >>>> might be buffering data because it can't transmit it until your > >>>> computer sets 'DTR' or 'RTS' or something like that. > >>>> > >>>> One way of bypassing hardware flow control is by using cables which > >>>> cross over certain wires so that the right signals are always being > >>>> sent; it's possible your old cable had these connections but your > >>>> current cable doesn't have them. If you can find the old cable, you > >>>> could put it back in and see if that fixes things? > >>>> > >>>> > >>>> 2009/9/8 Nathaniel S. Parsons : > >>>> > (Sorry if this is a double post, but I sent my original message > without > >>>> > subscribing, and since this is an urgent problem, I thought I'd > resend > >>>> > after > >>>> > subscribing to bypass the moderator limbo zone) > >>>> > > >>>> > Hi all, > >>>> > > >>>> > I've asked my question on StackOverflow already, so rather than > >>>> > copy-paste > >>>> > the question here, I'd like to redirect you there. > >>>> > > >>>> > Short version, I am no longer able to receive anything over RS-232 > with > >>>> > RXTX, but other programs work fine. I'm definitely sending things, > >>>> > because > >>>> > when I connect with a different program, all the responses to the > >>>> > commands I > >>>> > sent via RXTX arrive all at once. > >>>> > > >>>> > Everything was fine in the spring, so what could have happened? > Windows > >>>> > update? > >>>> > > >>>> > -Nate > >>>> > > >>>> > _______________________________________________ > >>>> > Rxtx mailing list > >>>> > Rxtx at qbang.org > >>>> > http://mailman.qbang.org/mailman/listinfo/rxtx > >>>> > > >>>> > > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at qbang.org > >>>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: connection_log.csv Type: application/octet-stream Size: 9725 bytes Desc: not available URL: From stefan.frings at vodafone.com Wed Sep 16 00:06:52 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Wed, 16 Sep 2009 08:06:52 +0200 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time Message-ID: Hello Daniel Weinand, your proble is surely related to my issue. Im not familiar with Mac OS, but I know that Linux and also Windows normally disconnect all USB devices during standby mode and reconnect them after power-on. RxTx seems to have a problem when a device disappears or appears while the C library is loaded. I think the C library should be changed to re-check the list of available ports whenever the Java application attempts to enumerate or open a port. And when a port disappears while it is open, the library should close it and throw an AlreadyClosedException. I think the Java application should be able to recover itself from temporarily lost devices, and it should also be able to open devices that have been plugged in AFTER the library was loaded. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.frings at vodafone.com Wed Sep 16 00:09:34 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Wed, 16 Sep 2009 08:09:34 +0200 Subject: [Rxtx] Reloading C library after USB error In-Reply-To: References: Message-ID: Hello Trent, Yes, I think the same. The library was obviously not written for USB devices. Is anybody aware of an alternative that works fine with USB / Hotpluggable devices? From stefan.frings at vodafone.com Wed Sep 16 00:12:58 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Wed, 16 Sep 2009 08:12:58 +0200 Subject: [Rxtx] RXTX on Ubuntu 9.04 with lock in /var/lock/LCK..ttyS0 Message-ID: Hello Petter, the serial ports are normally only writeable by root and by users that are in the dialout group. For your case, a solution might be, to add yourself to the dialout group in /etc/group. On my machines, RxTx wporks fine. I am using Ubuntu 8.10 and 9.04 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.frings at vodafone.com Wed Sep 16 00:17:27 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Wed, 16 Sep 2009 08:17:27 +0200 Subject: [Rxtx] FTDI chipset speed - much slower? Message-ID: Hello David, Im not 100% sure, but I highly assume that the delays are produces by the USB communication. USB transfers data in packets and there are large buffers of several hundreds characters, similar to ethernet. There is no real time communication. So when your software thinks that it has sent a character, this was not the case. It was only put into a buffer and will appears at the end of your USB2Serial cable after some time - I assume somewhat around 0,3ms. I noticed the same behavious with different USB2Serial adapters on Linux with plain C programs (not anything around Java and RxTx). -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 16 01:06:41 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 16 Sep 2009 10:06:41 +0300 Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby In-Reply-To: References: <4AAF5838.7080707@gmail.com> Message-ID: <0EB22ACB-0676-44DE-BBD3-A9D38CFD2E88@myller.com> Windows is not my primary platform, but I agree with Trent. I tested this too and noticed that ClearCommError() does not fail because RXTX loses fd (why would it), but because fd seems to no longer exist, or is reused, on kernel side. Resulting in access denied (5) error. Definitely something RXTX has no control of. Also the USB device re-registers itself, causing all it's previous file handles invalidated. After few seconds after waking from sleep, new ones can be created with CreateFile calls - as expected. FTDI chips can be reprogrammed not to do this reconnection cycle on USB sleep (with mprog 3.5 software). I dont know how well Windows follows that setting. Also Windows allows disabling USB power saving on specific USB devices. After those settings, it entirely up to the USB driver to do the right thing. .. which I'm not entirely sure it will - even if it's technically possible to retain fd's over sleep the driver might still be hardwired to reconnect the device on power save events. -- Basicly all these issues are about the fact that someone/something rips off the UART hardware RXTX is controlling. The serial comms features on most operating systems are not equipped to handle this since UART is expected to be integral part of the system. Well, USB has certainly changed that. Now not only the serial device can be unplugged (which is handled properly by protocols etc.) but the actual interface hardware too. Like ripping off the engine from your car while driving. For those reasons this issue is very hard for RXTX or any other serial comms library to handle. We could detect errors from kernel that indicate the UART has vanished and proceed to do automatic reopening of the serial port after some delay at the native lib. But: this has multiple issues, which probably will break user protocols and software. One of those is the fact that reopening the port could toggle its CTS/RTS/DTR/DSR signals causing unexpected trouble on user side. Other one is that we might end up in infinite loop of comm error <-> automatic reopening without notifying rxtx java side. Not elegant. Not proper. -- I'm proposing a following solution: We could implement a method to detect lost UART in event loop at native lib side and introduce a new Java side SerialPortEvent type UART_DISCONNECT. The native lib would send that event in case of error and proceed to automatically close the serial port and clear the invalid handles etc. (reset to fault free state). That would allow user code to gracefully handle these situations, by doing whatever is necessary to restore communications with their protocols etc. Usually that includes opening the serial port and doing some initializations. Those who choose to ignore that event, or not implement any handling for it, can continue to use RXTX as any other serial comms lib. But their software would still tumble and fall on UART disconnects - mostly caused by USB->UART bridges. Atleast, we'd have a method for implementing proper recovery if RXTX user chooses to do so. Beats duct tape+USB dongle combo anytime;) Feedback welcome :) -- I > > > On Tue, 15 Sep 2009, Daniel Weinand wrote: >> >> Error 0x5 at ..\src\termios.c(2712): Access Denied >> Error 0x5 at ..\src\termios.c(517): Access Denied >> ... > > It is a known problem. The kernel driver isnt restoring the fd. > See the previous post for what is required prior to being able to > handle it in your code. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 16 01:18:14 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 16 Sep 2009 10:18:14 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time In-Reply-To: References: Message-ID: I'm referring to my previous post and to my proposal for handling these situations (detection + java side event): In addition to UART_DISCONNECT event I proposed, your suggestion about AlreadyClosedException is great. We'd still have to handle existing "opened port objects" in Java side even after sending the UART_DISCONNECT event. Making them throw AlreadyClosedException would do that elegantly. -- I Frings, Stefan, VF-DE kirjoitti 16.9.2009 kello 9.06: > > And when a port disappears while it is open, the library should > close it and throw an AlreadyClosedException. > > I think the Java application should be able to recover itself from > temporarily lost devices, and it should also be able to open devices > that have been plugged in AFTER the library was loaded. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at attglobal.net Wed Sep 16 03:47:59 2009 From: david at attglobal.net (David Schmidt) Date: Wed, 16 Sep 2009 05:47:59 -0400 Subject: [Rxtx] FTDI chipset speed - much slower? In-Reply-To: References: <4AB044A0.10509@attglobal.net> Message-ID: <4AB0B44F.9060201@attglobal.net> Trent Jarvi wrote: > On Tue, 15 Sep 2009, David Schmidt wrote: >> I'm suspecting I'm doing something wrong along the way that is >> reacting badly with this chipset. My initial, lazy question, before >> exposing my code to the harsh light of day: is there anything obvious >> I might be doing wrong to this chipset to make it run so slowly? Has >> anyone else run into the same problem? > > Given that rxtx does not treat usb special, it may be something to do > with the nature of USB serial dongles. One suspicion I've had is that > the event loop is competing for bandwidth by trying to check the UART > status which is on the other side of the USB line. > > 1/5th is fairly significant. This is just writing/reading? How large > are the transfers? The protocol is a little dance that happens with tiny packets, rapidly sending/receiving (http://adtpro.sourceforge.net/protocol.html#Get). Host sends: 2 bytes: current block number (LSB, MSB) 1 byte: half-block number (2 = bytes 0-255, 1 = bytes 256-511) up to 256 bytes: Half-block, RLE encoded two bytes: CRC (lo) CRC (hi) Apple sends: One byte: acknowledgement Two bytes: current block number (LSB, MSB) One byte: half-block number (2 = bytes 0-255, 1 = bytes 256-511) (repeat) As others have mentioned, it may be the chipset waiting until that 16-byte on-chip buffer fills up, as the acknowledgment packet is really small. And, the payload packet size can be really small if all bytes are the same - RLE encoding would pack an "empty" block into just a few bytes too. - David From ozgurovic at hotmail.com Wed Sep 16 05:09:37 2009 From: ozgurovic at hotmail.com (Ozgur Erkent) Date: Wed, 16 Sep 2009 14:09:37 +0300 Subject: [Rxtx] FTDI chipset speed - much slower? In-Reply-To: <4AB0B44F.9060201@attglobal.net> References: <4AB044A0.10509@attglobal.net> <4AB0B44F.9060201@attglobal.net> Message-ID: Has anybody tried to experiment the latency time of FTDI USB2Serial? (its latency wrt serial port) after preferably sending command from the computer, probably by keeping track of time after command is sent, its echo back time. In different languages would be good to compare them. ?zg?r Erkent > Date: Wed, 16 Sep 2009 05:47:59 -0400 > From: david at attglobal.net > To: rxtx at qbang.org > Subject: Re: [Rxtx] FTDI chipset speed - much slower? > > Trent Jarvi wrote: > > On Tue, 15 Sep 2009, David Schmidt wrote: > >> I'm suspecting I'm doing something wrong along the way that is > >> reacting badly with this chipset. My initial, lazy question, before > >> exposing my code to the harsh light of day: is there anything obvious > >> I might be doing wrong to this chipset to make it run so slowly? Has > >> anyone else run into the same problem? > > > > Given that rxtx does not treat usb special, it may be something to do > > with the nature of USB serial dongles. One suspicion I've had is that > > the event loop is competing for bandwidth by trying to check the UART > > status which is on the other side of the USB line. > > > > 1/5th is fairly significant. This is just writing/reading? How large > > are the transfers? > > The protocol is a little dance that happens with tiny packets, rapidly > sending/receiving (http://adtpro.sourceforge.net/protocol.html#Get). > > Host sends: > 2 bytes: current block number (LSB, MSB) > 1 byte: half-block number (2 = bytes 0-255, 1 = bytes 256-511) > up to 256 bytes: Half-block, RLE encoded > two bytes: > CRC (lo) > CRC (hi) > > Apple sends: > One byte: acknowledgement > Two bytes: current block number (LSB, MSB) > One byte: half-block number (2 = bytes 0-255, 1 = bytes 256-511) > > (repeat) > > As others have mentioned, it may be the chipset waiting until that > 16-byte on-chip buffer fills up, as the acknowledgment packet is really > small. And, the payload packet size can be really small if all bytes > are the same - RLE encoding would pack an "empty" block into just a few > bytes too. > > - David > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ More than messages?check out the rest of the Windows Live?. http://www.microsoft.com/windows/windowslive/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Wed Sep 16 05:15:23 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Wed, 16 Sep 2009 07:15:23 -0400 (EDT) Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby In-Reply-To: <0EB22ACB-0676-44DE-BBD3-A9D38CFD2E88@myller.com> Message-ID: <11479259.481253099719746.JavaMail.gjohnson@pippin.local> This is a big problem for us, and one we have resorted to the duct tape solution for as we can't find anything better :( The notion of an additional event coming up from the native code sounds very promising! Cheers, greg -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com ----- Original Message ----- From: "Ilkka Myller" To: "Trent Jarvi" , "Daniel Weinand" , "Stefan Frings, VF-DE" Cc: "rxtx at qbang.org" Sent: Wednesday, September 16, 2009 3:06:41 AM GMT -05:00 US/Canada Eastern Subject: Re: [Rxtx] Error 0x5 in termios.c after wake-up from standby Windows is not my primary platform, but I agree with Trent. I tested this too and noticed that ClearCommError() does not fail because RXTX loses fd (why would it), but because fd seems to no longer exist, or is reused, on kernel side. Resulting in access denied(5) error. Definitely something RXTX has no control of. Also the USB device re-registers itself, causing all it's previous file handles invalidated. After few seconds after waking from sleep, new ones can be created with CreateFile calls - as expected. FTDI chips can be reprogrammed not to do this reconnection cycle on USB sleep (with mprog 3.5 software). I dont know how well Windows follows that setting. Also Windows allows disabling USB power saving on specific USB devices. After those settings, it entirely up to the USB driver to do the right thing. .. which I'm not entirely sure it will - even if it's technically possible to retain fd's over sleep the driver might still be hardwired to reconnect the device on power save events. -- Basicly all these issues are about the fact that someone/something rips off the UART hardware RXTX is controlling. The serial comms features on most operating systems are not equipped to handle this since UART is expected to be integral part of the system. Well, USB has certainly changed that. Now not only the serial device can be unplugged (which is handled properly by protocols etc.) but the actual interface hardware too. Like ripping off the engine from your car while driving. For those reasons this issue is very hard for RXTX or any other serial comms library to handle. We could detect errors from kernel that indicate the UART has vanished and proceed to do automatic reopening of the serial port after some delay at the native lib. But: this has multiple issues, which probably will break user protocols and software. One of those is the fact that reopening the port could toggle its CTS/RTS/DTR/DSR signals causing unexpected trouble on user side. Other one is that we might end up in infinite loop of comm error <-> automatic reopening without notifying rxtx java side. Not elegant. Not proper. -- I'm proposing a following solution: We could implement a method to detect lost UART in event loop at native lib side and introduce a new Java side SerialPortEvent type UART_DISCONNECT. The native lib would send that event in case of error and proceed to automatically close the serial port and clear the invalid handles etc. (reset to fault free state). That would allow user code to gracefully handle these situations, by doing whatever is necessary to restore communications with their protocols etc. Usually that includes opening the serial port and doing some initializations. Those who choose to ignore that event, or not implement any handling for it, can continue to use RXTX as any other serial comms lib. But their software would still tumble and fall on UART disconnects - mostly caused by USB->UART bridges. Atleast, we'd have a method for implementing proper recovery if RXTX user chooses to do so. Beats duct tape+USB dongle combo anytime;) Feedback welcome :) -- I On Tue, 15 Sep 2009, Daniel Weinand wrote: Error 0x5 at ..\src\termios.c(2712): Access Denied Error 0x5 at ..\src\termios.c(517): Access Denied ... It is a known problem. The kernel driver isnt restoring the fd. See the previous post for what is required prior to being able to handle it in your code. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Wed Sep 16 05:42:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 16 Sep 2009 05:42:08 -0600 (MDT) Subject: [Rxtx] FTDI chipset speed - much slower? In-Reply-To: References: Message-ID: On Wed, 16 Sep 2009, Frings, Stefan, VF-DE wrote: > Hello David, > ? > Im not 100% sure, but I highly assume that the delays are produces by the > USB communication. USB transfers data in packets and there are large > buffers of several hundreds characters, similar to ethernet. There is no > real time communication. > ? > So when your software thinks that it has sent a character, this was not > the case. It was only put into a buffer and will appears at the end of > your USB2Serial cable after some time - I assume somewhat around 0,3ms. > ? > I noticed the same behavious with different USB2Serial adapters on Linux > with plain C programs (not anything around Java and RxTx). > ? I have seen some simple native C applications that do not inspect the LSR manage to send bytes closer to how an onboard UART does. In that case it was just two bytes being observed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Sep 16 05:55:14 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 16 Sep 2009 05:55:14 -0600 (MDT) Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby In-Reply-To: <0EB22ACB-0676-44DE-BBD3-A9D38CFD2E88@myller.com> References: <4AAF5838.7080707@gmail.com> <0EB22ACB-0676-44DE-BBD3-A9D38CFD2E88@myller.com> Message-ID: I think that will be fine. I'm not sure about all the corner cases with bluetooth dongles. On Wed, 16 Sep 2009, Ilkka Myller wrote: > Windows is not my primary platform, but I agree with Trent. > > I tested this too and noticed that ClearCommError() does not fail because > RXTX loses fd (why would it), but because fd seems to no longer exist, or > is reused, on kernel side. Resulting in access denied(5) error. > Definitely something RXTX has no control of. > Also the USB device re-registers itself, causing all it's previous file > handles invalidated. After few seconds after waking from sleep, new ones > can be created with CreateFile calls - as expected. > > FTDI chips can be reprogrammed not to do this reconnection cycle on USB > sleep (with mprog 3.5 software). I dont know how well Windows follows > that setting. Also Windows allows disabling USB power saving on specific > USB devices. > > After those settings, it entirely up to the USB driver to do the right > thing. .. which I'm not entirely sure it will - even if it's technically > possible to retain fd's over sleep the driver might still be hardwired to > reconnect the device on power save events. > > -- > > Basicly all these issues are about the fact that someone/something rips > off the UART hardware RXTX is controlling. The serial comms features on > most operating systems are not equipped to handle this since UART is > expected to be integral part of the system. Well, USB has certainly > changed that.? > Now not only the serial device can be unplugged (which is handled > properly by protocols etc.) but the actual interface hardware too. Like > ripping off the engine from your car while driving. > > For those reasons this issue is very hard for RXTX or any other serial > comms library to handle. We could detect errors from kernel that indicate > the UART has vanished and proceed to do automatic reopening of the serial > port after some delay at the native lib. But: this has multiple issues, > which probably will break user protocols and software. One of those is > the fact that reopening the port could toggle its CTS/RTS/DTR/DSR signals > causing unexpected trouble on user side. Other one is that we might end > up in infinite loop of comm error <-> automatic reopening without > notifying rxtx java side. Not elegant. Not proper. > > -- > > I'm proposing a following solution: > > We could implement a method to detect lost UART in event loop at native > lib side and introduce a new Java side SerialPortEvent type > UART_DISCONNECT.?The native lib would send that event in case of error > and proceed to automatically close the serial port and clear the invalid > handles etc. (reset to fault free state). > > That would allow user code to gracefully handle these situations, by > doing whatever is necessary to restore communications with their > protocols etc. Usually that includes opening the serial port and doing > some initializations. > > Those who choose to ignore that event, or not implement any handling for > it, can continue to use RXTX as any other serial comms lib. But their > software would still tumble and fall on UART disconnects - mostly caused > by USB->UART bridges. > > Atleast, we'd have a method for implementing proper recovery if RXTX user > chooses to do so. Beats duct tape+USB dongle combo anytime;) > > Feedback welcome :)? > > -- > I > > > > On Tue, 15 Sep 2009, Daniel Weinand wrote: > > Error 0x5 at ..\src\termios.c(2712): Access > Denied > > Error 0x5 at ..\src\termios.c(517): Access Denied > > ... > > > It is a known problem. ?The kernel driver isnt restoring the > fd. ?See the previous post for what is required prior to > being able to handle it in your code. > > > From tjarvi at qbang.org Wed Sep 16 18:10:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 16 Sep 2009 18:10:42 -0600 (MDT) Subject: [Rxtx] Fwd: [Patch] Implement new UART_DISCONNECT event (fwd) Message-ID: Attachments are pending. They got caught by the size restrictions. > L?hett?j?: Ilkka Myller > P?iv?ys: 17. syyskuuta 2009 0.14.50 UTC+3.00 > Vastaanottaja: "rxtx at qbang.org" > Aihe: [Patch] Implement new UART_DISCONNECT event > > > Summary: > > This patch adds support for new SerialPortEvent.UART_DISCONNECT event. > > Backwards compatibility: > > If RXTX user does not register event listener and request UART_DISCONNECT > events, the RXTX functions same as before. (=does not react to UART > disconnects - or behaviour is unspecified). > > Implementation: > > 1. The RXTX native lib eventLoop() checks for UART disconnection (for example > USB Adapter unplug/powersave) and sends UART_DISCONNECT event to interested > Java listeners. This happens as soon as serial ports file descriptor/handle > becomes invalid or points to no longer existing serial port driver io's. > Sometimes the UART drivers accept writes/reads few seconds after actual > disconnect (this is normal and depends on OS and the driver used). > > 2. The Java send_event() closes serial ports automatically and forwards the > UART_DISCONNECT event to user code/listener. > > 3. Subsequent calls to any RXTXPort IO function (except close() or > removeEventListener()) throws PortAlreadyClosedException which is subclass of > IOException --> no code changes necessary if IOExceptions are already handled > in user code. This is for backwards compatibility. > > 4. It's up to the user code to handle the proper recovery after receiving the > UART_DISCONNECT (usually involves trying to reopen the port and reinitialize > protocols) > > How UART disconnect is detected: > > eventLoop() uses conditionally defined CHECK_FD(int fd) function to check if > file descriptor points to valid (and existing) serial port. On windows this > means calling termios_check_fd() function and all others call > posix_check_fd() function. > > On linux/mac/other posix, CHECK_FD calls fstat, fcntl and ioctl (with > non-port-state-altering parameters) to check if file descriptor is valid and > device driver behind it responds properly. > > On windows, CHECK_FD calls GetCommState() to check if serial port handle is > still valid and port is accessible. > > If someone knows a better way (less overhead) to check if fd is valid, please > let me know:) Checking fd value >0 is not enough, since we have to detect if > UART driver actually responds even when we have fd > 0 too. > > Patch: > > The included patch is against CVS (@2009/09/16). > It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < > im-uart-disconnect1.patch' in rxtx-devel/src directory. > > The patch file does not include gnu/io/PortAlreadyClosedException.java, which > is included as separate attachment. > You must place this to rxtx-devel/src/gnu/io directory. > > Demonstration code: > > I've also included a simple demonstration code to test this feature. I've > tested it on Windows and on Mac OS X. > The SerialReconnectDemo(.java) writes few bytes to the serial port > continuously every 500ms. > If UART_DISCONNECT is received, it goes into reconnect() loop in separate > thread and tries to re-establish serial port connection. > If connection can be re-established, it continues operation normally. > It uses ReentrantLocks to properly synchronize serial port operations, which > is very useful with reconnect and writes --> if going to reconnect mode, > writes are blocked until connection is re-established. > > The demonstration code nicely survives from random disconnects of USB Serial > adapter. > > > Feedback: > > This is highly experimental implementation and details are likely to change. > Testing and any feedback is more than welcome. > Especially Trent, any thoughts? Am I missing something here? > > > > Thanks, > > -- > I > > > > > > > > From stefan.frings at vodafone.com Thu Sep 17 00:22:40 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Thu, 17 Sep 2009 08:22:40 +0200 Subject: [Rxtx] RXTX on Ubuntu 9.04 with lock in /var/lock/LCK..ttyS0 In-Reply-To: References: Message-ID: Hello petter, I installed the C library through using apt and I copied the jar file to the lib folder of my Java application. The I added myself to the dialout group. Nothing else. --- Good morning. Tanks for help me. I added the User and now with RXTX did not signal more trouble to lock the serial port, but my Java application can no longer capture the data (in my case shipped weight of an electronic scale). It is very strange, because Windows works normally, you know if Linux is needed any more setup RXTX to work well? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.frings at vodafone.com Thu Sep 17 00:25:56 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Thu, 17 Sep 2009 08:25:56 +0200 Subject: [Rxtx] FTDI chipset speed - much slower? Message-ID: Hello Ozgur, I can tell you a value from Silabs CP2102 chip. With a simple loopback connection on the serial end and a bitrate of 115200 (everything else left to the default settings), using Linux, the echo of 1-10 characters comes always back withing one milliseconds in a Java application using RxTxComm. I am not able to measure it more exactly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.frings at vodafone.com Thu Sep 17 00:31:35 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Thu, 17 Sep 2009 08:31:35 +0200 Subject: [Rxtx] RxTx handling disconnected USB devices Message-ID: Hello Ilkka, I highly appreciate your recommendation. The Java application should decide what to do when the device gets disconnected. When I disconnect /dev/ttyUSB0 and then reconnect it, I want to be able to re-open that port. Currently, this is not the case, because RxTxComm does not close it when I disconnect the device. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Thu Sep 17 00:44:24 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 17 Sep 2009 09:44:24 +0300 Subject: [Rxtx] [Patch] New feature: Implemented UART_DISCONNECT event Message-ID: <6E51B6F1-41C3-4FD5-B4A9-CBFD4AF83C85@myller.com> Summary: This patch implements new SerialPortEvent.UART_DISCONNECT event. Backwards compatibility: If RXTX user does not register event listener and request UART_DISCONNECT events, the RXTX functions same as before. (=does not react to UART disconnects - or behaviour is unspecified). Implementation: 1. The RXTX native lib eventLoop() checks for UART disconnection (for example USB Adapter unplug/powersave) and sends UART_DISCONNECT event to interested Java listeners. This happens as soon as serial ports file descriptor/handle becomes invalid or points to no longer existing serial port driver io's. Sometimes the UART drivers accept writes/ reads few seconds after actual disconnect (this is normal and depends on OS and the driver used). 2. The Java send_event() closes serial ports automatically and forwards the UART_DISCONNECT event to user code/listener. 3. Subsequent calls to any RXTXPort IO function (except close() or removeEventListener()) throws PortAlreadyClosedException which is subclass of IOException --> no code changes necessary if IOExceptions are already handled in user code. This is for backwards compatibility. 4. It's up to the user code to handle the proper recovery after receiving the UART_DISCONNECT (usually involves trying to reopen the port and reinitialize protocols) How UART disconnect is detected: eventLoop() uses conditionally defined CHECK_FD(int fd) function to check if file descriptor points to valid (and existing) serial port. On windows this means calling termios_check_fd() function and all others call posix_check_fd() function. On linux/mac/other posix, CHECK_FD calls fstat, fcntl and ioctl (with non-port-state-altering parameters) to check if file descriptor is valid and device driver behind it responds properly. On windows, CHECK_FD calls GetCommState() to check if serial port handle is still valid and port is accessible. If someone knows a better way (less overhead) to check if fd is valid, please let me know:) Checking fd value >0 is not enough, since we have to detect if UART driver actually responds even when we have fd > 0 too. Patch: The patch file is against CVS (@2009/09/16). It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < im- uart-disconnect1.patch' in rxtx-devel/src directory. The patch file does not include gnu/io/ PortAlreadyClosedException.java, which is included as separate file. You must place this to rxtx-devel/src/gnu/io directory. Due to mailing list restrictions, the attachments are inside .tar.gz archive. Demonstration code: I've also included a simple demonstration code to test this feature. I've tested it on Windows and on Mac OS X. The SerialReconnectDemo(.java) writes few bytes to the serial port continuously every 500ms. If UART_DISCONNECT is received, it goes into reconnect() loop in separate thread and tries to re-establish serial port connection. If connection can be re-established, it continues operation normally. It uses ReentrantLocks to properly synchronize serial port operations, which is very useful with reconnect and writes --> if going to reconnect mode, writes are blocked until connection is re-established. The demonstration code nicely survives from random disconnects of USB Serial adapter. Feedback: This is highly experimental implementation and details are likely to change. Testing and any feedback is more than welcome. Especially Trent, any thoughts? Am I missing something here? Thanks, -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im-uart-disconnect-1.tar.gz Type: application/x-gzip Size: 11834 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 16 22:49:25 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 17 Sep 2009 07:49:25 +0300 Subject: [Rxtx] [Patch] New feature: Implemented UART_DISCONNECT event Message-ID: <7E5DCEB5-650B-41F5-A2F3-861B96BAA00F@myller.com> Summary: This patch adds support for new SerialPortEvent.UART_DISCONNECT event. Backwards compatibility: If RXTX user does not register event listener and request UART_DISCONNECT events, the RXTX functions same as before. (=does not react to UART disconnects - or behaviour is unspecified). Implementation: 1. The RXTX native lib eventLoop() checks for UART disconnection (for example USB Adapter unplug/powersave) and sends UART_DISCONNECT event to interested Java listeners. This happens as soon as serial ports file descriptor/handle becomes invalid or points to no longer existing serial port driver io's. Sometimes the UART drivers accept writes/ reads few seconds after actual disconnect (this is normal and depends on OS and the driver used). 2. The Java send_event() closes serial ports automatically and forwards the UART_DISCONNECT event to user code/listener. 3. Subsequent calls to any RXTXPort IO function (except close() or removeEventListener()) throws PortAlreadyClosedException which is subclass of IOException --> no code changes necessary if IOExceptions are already handled in user code. This is for backwards compatibility. 4. It's up to the user code to handle the proper recovery after receiving the UART_DISCONNECT (usually involves trying to reopen the port and reinitialize protocols) How UART disconnect is detected: eventLoop() uses conditionally defined CHECK_FD(int fd) function to check if file descriptor points to valid (and existing) serial port. On windows this means calling termios_check_fd() function and all others call posix_check_fd() function. On linux/mac/other posix, CHECK_FD calls fstat, fcntl and ioctl (with non-port-state-altering parameters) to check if file descriptor is valid and device driver behind it responds properly. On windows, CHECK_FD calls GetCommState() to check if serial port handle is still valid and port is accessible. If someone knows a better way (less overhead) to check if fd is valid, please let me know:) Checking fd value >0 is not enough, since we have to detect if UART driver actually responds even when we have fd > 0 too. Patch: The included patch is against CVS (@2009/09/16). It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < im- uart-disconnect1.patch' in rxtx-devel/src directory. The patch file does not include gnu/io/ PortAlreadyClosedException.java, which is included as separate attachment. You must place this to rxtx-devel/src/gnu/io directory. Demonstration code: I've also included a simple demonstration code to test this feature. I've tested it on Windows and on Mac OS X. The SerialReconnectDemo(.java) writes few bytes to the serial port continuously every 500ms. If UART_DISCONNECT is received, it goes into reconnect() loop in separate thread and tries to re-establish serial port connection. If connection can be re-established, it continues operation normally. It uses ReentrantLocks to properly synchronize serial port operations, which is very useful with reconnect and writes --> if going to reconnect mode, writes are blocked until connection is re-established. The demonstration code nicely survives from random disconnects of USB Serial adapter. Feedback: This is highly experimental implementation and details are likely to change. Testing and any feedback is more than welcome. Especially Trent, any thoughts? Am I missing something here? Thanks, -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im-uart-disconnect-1.patch Type: application/octet-stream Size: 44545 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PortAlreadyClosedException.java Type: application/octet-stream Size: 3606 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialReconnectDemo.java Type: application/octet-stream Size: 5781 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Sep 17 21:20:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 17 Sep 2009 21:20:53 -0600 (MDT) Subject: [Rxtx] [Patch] New feature: Implemented UART_DISCONNECT event In-Reply-To: <7E5DCEB5-650B-41F5-A2F3-861B96BAA00F@myller.com> References: <7E5DCEB5-650B-41F5-A2F3-861B96BAA00F@myller.com> Message-ID: On Thu, 17 Sep 2009, Ilkka Myller wrote: > > Summary: > > This patch adds support for new SerialPortEvent.UART_DISCONNECT event. > > Backwards compatibility: > > If RXTX user does not register event listener and request UART_DISCONNECT > events, the RXTX functions same as before. (=does not react to UART > disconnects - or behaviour is unspecified). > We have a section of methods that are extensions to the API at the bottom of the file. These are commented clearly as extensions for javadoc. The register method should go there. > Implementation: > > 1. The RXTX native lib eventLoop() checks for UART disconnection (for > example USB Adapter unplug/powersave) and sends UART_DISCONNECT event to > interested Java listeners. This happens as soon as serial ports file > descriptor/handle becomes invalid or points to no longer existing serial > port driver io's. Sometimes the UART drivers accept writes/reads few > seconds after actual disconnect (this is normal and depends on OS and the > driver used). > > 2. The Java send_event() closes serial ports automatically and forwards > the UART_DISCONNECT event to user code/listener. > > 3. Subsequent calls to any RXTXPort IO function (except close() or > removeEventListener()) throws PortAlreadyClosedException which is subclass > of IOException --> no code changes necessary if IOExceptions are already > handled in user code. This is for backwards compatibility. > I suspect this is a bit of a problem as it forces people to handle IOExceptions they normally didnt. Hmm. We may want to look at that again. I personally am OK with it but I think people should look it over. > 4. It's up to the user code to handle the proper recovery after receiving > the UART_DISCONNECT (usually involves trying to reopen the port and > reinitialize protocols) > > How UART disconnect is detected: > > eventLoop() uses conditionally defined CHECK_FD(int fd) function to check > if file descriptor points to valid (and existing) serial port. On windows > this means calling termios_check_fd() function and all others call > posix_check_fd() function. > > On linux/mac/other posix, CHECK_FD calls fstat, fcntl and ioctl (with > non-port-state-altering parameters) to check if file descriptor is valid > and device driver behind it responds properly. > > On windows, CHECK_FD calls GetCommState() to check if serial port handle > is still valid and port is accessible. > > If someone knows a better way (less overhead) to check if fd is valid, > please let me know:) Checking fd value >0 is not enough, since we have to > detect if UART driver actually responds even when we have fd > 0 too. > Looks good overall. I worry that there may be paths to deadlock on w32 as various layers try to redundantly make sure a write or read happens. I also worry that the new method signatures with exceptions will require code changes in older applications even though they extend IOExceptions. The windows checks are fine vs implementing a POSIX version. -- Trent Jarvi tjarvi at qbang.org From ilkka at myller.com Thu Sep 17 23:29:10 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 18 Sep 2009 08:29:10 +0300 Subject: [Rxtx] [Patch] New feature: Implemented UART_DISCONNECT event In-Reply-To: References: <7E5DCEB5-650B-41F5-A2F3-861B96BAA00F@myller.com> Message-ID: > > > We have a section of methods that are extensions to the API at the > bottom of the file. These are commented clearly as extensions for > javadoc. The register method should go there. > I agree. I'll move the method there. >> >> 3. Subsequent calls to any RXTXPort IO function (except close() or >> removeEventListener()) throws PortAlreadyClosedException which is >> subclass of IOException --> no code changes necessary if >> IOExceptions are already handled in user code. This is for >> backwards compatibility. >> > > I suspect this is a bit of a problem as it forces people to handle > IOExceptions they normally didnt. Hmm. We may want to look at that > again. I personally am OK with it but I think people should look it > over. > I do not think this is a problem for methods that already did throw IOException, but for those API extension-methods that previously did not? right? I did not add PortAlreadyClosed exception to any stuff that we inherit from Comm API. I assumed we can change our own extensions relatively freely if necessary. I changed the notify....() methods to handle the closed-serial-port - situation by making them do nothing in that case. They only change something if isOpen() returns true. Therefore they dont have to throw PortAlreadyClosedExceptions. That's fine, because they also dont have to return any values since they are void. But those RXTX extension methods that I modified to throw the new exception, usually return some values. If we make them to behave like notify..(), they still have to return something - with closed serial port. What value would that be? Determining proper return value for those is bit difficult since they obviously cant call native methods with fd==0.. So basicly, that is why I chose to throw PortAlreadyClosed exception from them. The alternative did not feel any better. I hate to change the API ... even RXTX extensions ... but I think it's the right thing to do here if we want to implement this feature. As an example, the current implementation with added new exception.... public byte getParityErrorChar( ) throws UnsupportedCommOperationException, PortAlreadyClosedException { byte ret; checkPortAlreadyClosed(); ret = nativeGetParityErrorChar(); return( ret ); } ..versus non PortAlreadyClosed -exception alternative.. public byte getParityErrorChar( ) throws UnsupportedCommOperationException { if ( isOpen() == true ) { byte ret; ret = nativeGetParityErrorChar(); return( ret ); } else { return ( ); } } Thats the problem. We could however, throw UnsupportedCommOperationException and keep the method interface intact. But that would break the contract for the usage/meaning of UnsupportedCommOperationException ... and causes even more trouble for users. > > I worry that there may be paths to deadlock on w32 as various layers > try to redundantly make sure a write or read happens. We dont want that. Did you notice that I replaced fd verification in read/write with new termios_check_fd()'s.? Any ideas? > The windows checks are fine vs implementing a POSIX version. > I still feel that those checks are not optimal. There should be a cleaner way to verify that device driver responds behind fd.. instead of just requesting status registers from it. -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Fri Sep 18 05:27:43 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 18 Sep 2009 13:27:43 +0200 Subject: [Rxtx] Checking jni calls Message-ID: <7a803d460909180427h6a43b0c8i89734888aac2ffd4@mail.gmail.com> Hi I am trying to troubleshoot our code that talks to several devices on the serial port using RXTX, and I came across a tip from sun to run the java code with the -Xcheck:jni flag set. The code did not run very long before failing. Does anyone know what line of code in the eventLoop is causing this failure (I'm running this code on Windows XP 32bit)? I would like to patch this and create a new personal build of RXTX that runs even with the check:jni flag set. ... Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 18 Sep 2009 11:16:57,244 DEBUG serial.DeviceSerialConnection, line 90 - Opening COM-port on COM22 FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1575) -- Kjetil ?ster?s From tjarvi at qbang.org Tue Sep 1 02:38:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 1 Sep 2009 02:38:40 -0600 (MDT) Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks Ilkka The problem should be resolved (confirmed from two locations). I'll be trying to hunt down a Snow Leopard box tomorrow evening as well. On Tue, 1 Sep 2009, Ilkka Myller wrote: > Hi, > > CVS server is reachable, but when trying anonymous login it replies: > > " > Fatal error, aborting. > anonymous: no such system user > " > > It seems that the anonymous cvs account is not yet properly configured on the > new system. > > -- > I > >> On Mon, 31 Aug 2009, Trent Jarvi wrote: >> >> The server has been beemed to another location for those experiencing >> routing problems. >> >> in bash: >> >> export CVSROOT=:pserver:anonymous at qbang.org:2401/var/cvs/cvsroot >> cvs login (no passwd) >> cvs co -r commapi-0-0-1 rxtx-devel >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Tue Sep 1 03:05:59 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 12:05:59 +0300 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks, The new CVS server works well :) I can also confirm that latest CVS version builds properly with unmodified Snow Leopard (Mac OS X 10.6) system: Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 gcc version 4.2.1 (Apple Inc. build 5646) Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) --> Resulting JNI library (Universal Binary): i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = 9d15fc488b301da8bf65b2c9456a7bbb --> Resulting JAR: RXTXComm.jar / 60942 bytes MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 Atleast it builds.. and probably works too. I have not tested that yet. -- I Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > The problem should be resolved (confirmed from two locations). I'll > be trying to hunt down a Snow Leopard box tomorrow evening as well. From jimmy.lee at emotum.com Tue Sep 1 05:07:19 2009 From: jimmy.lee at emotum.com (Jimmy Lee [emotum]) Date: Tue, 1 Sep 2009 21:07:19 +1000 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: <112685a90909010407i6054acb5tc2b12196797bfaf1@mail.gmail.com> Could we access to the binaries? Please :) 2009/9/1 Ilkka Myller > Thanks, > > The new CVS server works well :) > > I can also confirm that latest CVS version builds properly with unmodified > Snow Leopard (Mac OS X 10.6) system: > > Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_I386 i386 > gcc version 4.2.1 (Apple Inc. build 5646) > Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) > > > --> Resulting JNI library (Universal Binary): > > i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes > > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 > librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc > > MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = > 9d15fc488b301da8bf65b2c9456a7bbb > > > --> Resulting JAR: > > RXTXComm.jar / 60942 bytes > > MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 > > > > Atleast it builds.. and probably works too. I have not tested that yet. > > -- > I > > Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > > The problem should be resolved (confirmed from two locations). I'll be >> trying to hunt down a Snow Leopard box tomorrow evening as well. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Tue Sep 1 06:21:28 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Tue, 1 Sep 2009 08:21:28 -0400 (EDT) Subject: [Rxtx] Snow Leopard binaries Message-ID: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> +1 for binaries - pretty please with sugar on top... -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com From fredm at alum.mit.edu Tue Sep 1 06:24:17 2009 From: fredm at alum.mit.edu (Fred G. Martin) Date: Tue, 1 Sep 2009 08:24:17 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> Message-ID: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> You can find one here: http://iharder.sourceforge.net/current/java/ Also, you need to add yourself (any rxtx user) to the uucp group. Niutils don't exist, but dscl is a replacement. There is info for using it here: http://aplawrence.com/MacOSX/directory_services.html Fred On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Tue Sep 1 07:03:37 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Tue, 1 Sep 2009 18:33:37 +0530 Subject: [Rxtx] Help for RXTX on mac Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time I am able to read the device but on second time, it hangs on COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then it was showing the PortInUseException, I replaced the RXTX library to 2.2Pre1 so it is showing this problem. Is this is a problem with RXTX on Mac? Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: From ilkka at myller.com Tue Sep 1 07:57:06 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 16:57:06 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:02:31 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:02:31 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:43:49 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:43:49 +0300 Subject: [Rxtx] Help for RXTX on mac In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE@myller.com> Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Arseneau at Sun.COM Tue Sep 1 08:51:32 2009 From: Eric.Arseneau at Sun.COM (Eric Arseneau) Date: Tue, 01 Sep 2009 07:51:32 -0700 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24@sun.com> Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 09:24:30 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 18:24:30 +0300 Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D@myller.com> Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Thu Sep 3 02:50:16 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Thu, 3 Sep 2009 10:50:16 +0200 Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s From Kapil_Gupta at hcl.in Thu Sep 3 06:52:21 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:22:21 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From Kapil_Gupta at hcl.in Thu Sep 3 07:15:19 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:45:19 +0530 Subject: [Rxtx] Rxtx Digest, Vol 25, Issue 3 In-Reply-To: References: Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C50BB@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi myller, I have attached the code with the mail. Please help me if I am doing something wrong in it. Thanks & Regards, Kapil Gupta -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of rxtx-request at qbang.org Sent: Thursday, September 03, 2009 4:15 PM To: rxtx at qbang.org Subject: Rxtx Digest, Vol 25, Issue 3 Send Rxtx mailing list submissions to rxtx at qbang.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qbang.org/mailman/listinfo/rxtx or, via email, send a message with subject or body 'help' to rxtx-request at qbang.org You can reach the person managing the list at rxtx-owner at qbang.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Rxtx digest..." Today's Topics: 1. Re: Snow Leopard binaries (Ilkka Myller) 2. Re: Snow Leopard binaries (Ilkka Myller) 3. Re: Help for RXTX on mac (Ilkka Myller) 4. Re: Snow Leopard binaries (Eric Arseneau) 5. Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters (Ilkka Myller) 6. RXTX multiple crashes (Kjetil ?ster?s) 7. RXTX 2.2Pre + MacMini+ Deadlock while second time port open (Kapil Gupta) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Sep 2009 16:57:06 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 1 Sep 2009 17:02:31 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <55EC133D-DC83-45A3-849C-02714904D580 at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 1 Sep 2009 17:43:49 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Help for RXTX on mac Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Tue, 01 Sep 2009 07:51:32 -0700 From: Eric Arseneau Cc: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24 at sun.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 1 Sep 2009 18:24:30 +0300 From: Ilkka Myller To: rxtx Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Thu, 3 Sep 2009 10:50:16 +0200 From: Kjetil ?ster?s To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s ------------------------------ Message: 7 Date: Thu, 3 Sep 2009 18:22:21 +0530 From: Kapil Gupta To: "rxtx at qbang.org" Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059 at NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset="us-ascii" Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: ------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx End of Rxtx Digest, Vol 25, Issue 3 *********************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From ilkka at myller.com Thu Sep 3 11:17:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 3 Sep 2009 20:17:27 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <4520677F-E8F0-46F5-B4AD-3AD3A7C2AED3@myller.com> Hi Kapil, The code is incomplete and I did not find anything I could to test/ debug with this. I also tried to find the actual serial port opening, but found only a call to missing method which creates the SerialPort object (?): serialPort = getSerialPortConnection( COMPort, this.readEvent.getDeviceName(), SerialCommConfig.DEVICE1[SerialCommConfig.TIMEOUT], SerialCommConfig.DEVICE1[SerialCommConfig.BAUDRATE], SerialCommConfig.DEVICE1[SerialCommConfig.DATABITS], SerialCommConfig.DEVICE1[SerialCommConfig.STOPBITS], SerialCommConfig.DEVICE1[SerialCommConfig.PARITY] ); The class SerialCommConfig is missing too. If this is a part of the actual code you are using, please note that you are not actually closing the serial port. The call to close() method is commented out: try { // serialPort.close(); } catch (Exception ex) { ex.printStackTrace(); } Re-opening of the serial port wont work if you haven't properly closed it first. -- I > > I am using RXTX on Macintosh to communicate to my device. First time > the device responds well but on second time, it hangs on > COMPort.open (name, timeout). > > I have attached the source code in a file. Please help me. > > Thanks & Best Regards, > Kapil -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorton at intellimec.com Thu Sep 3 11:37:55 2009 From: dmorton at intellimec.com (Daniel Morton) Date: Thu, 3 Sep 2009 13:37:55 -0400 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. (I haven't tried previous version though). Daniel Morton Java/J2EE Developer Tel +1 519.745.8887 x4331 Email dmorton at intellimec.com www.intellimec.com | www.iLane.com | www.drivesync.com Intelligent Mechatronic Systems Inc. 435 King Street North Waterloo, ON N2J 2Z5 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s Sent: Thursday, September 03, 2009 4:50 AM To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. From alexanderkiel at gmx.net Fri Sep 4 02:29:15 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 10:29:15 +0200 Subject: [Rxtx] Official Javadoc Location Message-ID: <1252052955.4025.80.camel@T61-KIEL> Hi List, I wasn't able to find an official location of RXTX Javadoc accessible over HTTP. Maybe someone can link me to it. If there is no such location, I would like to see one. I like to link from my own Javadoc to such a location. Thanks Alexander - e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:19:25 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:19:25 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> Message-ID: <1252055965.4025.84.camel@T61-KIEL> Hi Michael, thanks for the pointer. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 09:48 +0100, Michael Tandy wrote: > RxTx javadoc: http://users.frii.com/jarvi/rxtx/doc/index.html > Javax interface RxTx duplicates javadoc: > http://java.sun.com/products/javacomm/reference/api/index.html > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:22:14 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:22:14 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> Message-ID: <1252056134.4025.87.camel@T61-KIEL> Hi Eike, thanks, but I need a direct package pointer so that Javadoc will link the gnu.io packages automatically to the right location. Michael has pointed me to http://users.frii.com/jarvi/rxtx/doc/index.html which has the gnu.io packages. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 11:04 +0200, Eike Hinderk J?rrens wrote: > Hi Alexander, > it seems to me that RXTX is implementing this API: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Kind regards, > Eike > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kjetilos at gmail.com Fri Sep 4 03:43:41 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 11:43:41 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> Message-ID: <7a803d460909040243ke4449ecucbe2cd8b15761746@mail.gmail.com> Hi Daniel, This is interesting, what type of application are you making? Is there a lot of signaling on different COM ports at the same time in your application? In our application we have 11 devices connected to different COM ports, 9 of these are in active use when the application is running. I'm wondering how to use the RXTX library version 2.1.7 in this scenario without causing it to crash. After adding more signaling on the COM ports in our application we have now experienced other crashes and it is natural to think that it has something to do with our way of using RXTX from several threads at the same time. So my question is are there any methods like read/write/flush/close that are not thread safe and should be handled with care? And similarly is the RXTXPort.SerialInputStream and RXTXPort.SerialOutputStream thread safe? 2009/9/3 Daniel Morton : > I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. ?(I haven't tried previous version though). > > Daniel Morton > Java/J2EE Developer > > Tel ? ?+1 519.745.8887 x4331 > Email ? ?dmorton at intellimec.com > > > www.intellimec.com ?| ?www.iLane.com ?| ?www.drivesync.com > > > > Intelligent Mechatronic Systems Inc. > 435 King Street North Waterloo, ON N2J 2Z5 > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s > Sent: Thursday, September 03, 2009 4:50 AM > To: rxtx at qbang.org > Subject: [Rxtx] RXTX multiple crashes > > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x7d0d] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0ce75800): ?JavaThread "Y Worker" daemon > [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 > > Registers: > EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 > ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 > EIP=0x10007d0d, EFLAGS=0x00010202 > > Top of Stack: (sp=0x0d7ff6d8) > 0x0d7ff6d8: ? 0d7ff700 00000000 00000000 00000000 > 0x0d7ff6e8: ? 02a2eae8 00000123 00002958 0d7ff718 > 0x0d7ff6f8: ? 7c830887 7c90d28a 7c8664b5 00000e2c > 0x0d7ff708: ? 00002958 00000000 00000000 7c90cffa > 0x0d7ff718: ? 7c809bdb 00002958 0d7ff758 00000e40 > 0x0d7ff728: ? 00002958 02bd0468 0ce75800 080e4ee0 > 0x0d7ff738: ? 00000000 00000000 00000000 00000000 > 0x0d7ff748: ? 00000000 00000000 00000014 7c90d09a > > Instructions: (pc=0x10007d0d) > 0x10007cfd: ? 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 > 0x10007d0d: ? 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 > > > Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x7d0d] > J ?gnu.io.RXTXPort.nativeDrain(Z)Z > J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > ... > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x9c55] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0cddf400): ?JavaThread "XXX Worker" daemon > [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 > > Registers: > EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 > ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 > EIP=0x10009c55, EFLAGS=0x00010206 > > Top of Stack: (sp=0x0bb8f830) > 0x0bb8f830: ? 00000000 00000000 c0000005 00000000 > 0x0bb8f840: ? 00000000 00f1f0a5 00000002 00000000 > 0x0bb8f850: ? 003a0100 0001003f 0bb8fb20 0b9ff918 > 0x0bb8f860: ? 00000000 00000000 0bb8fb68 0bb8fb20 > 0x0bb8f870: ? 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 > 0x0bb8f880: ? 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 > 0x0bb8f890: ? 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 > 0x0bb8f8a0: ? 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 > > Instructions: (pc=0x10009c55) > 0x10009c45: ? 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff > 0x10009c55: ? 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 > > > Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x9c55] > C ?[rxtxSerial.dll+0xa05e] > J ?gnu.io.RXTXPort.readByte()I > J ?gnu.io.RXTXPort$SerialInputStream.read()I > J ?java.io.FilterInputStream.read()I > ... > > -- > Kjetil ?ster?s > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kjetil ?ster?s From tjarvi at qbang.org Fri Sep 4 06:00:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Sep 2009 06:00:40 -0600 (MDT) Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x7d0d] > J gnu.io.RXTXPort.nativeDrain(Z)Z > J gnu.io.RXTXPort$SerialOutputStream.flush()V > Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x9c55] > C [rxtxSerial.dll+0xa05e] > J gnu.io.RXTXPort.readByte()I > J gnu.io.RXTXPort$SerialInputStream.read()I RXTX 2.1-7 has concurrency issues that will show upon multicore systems. These should be resolved in the 2.2 pre release. A user application could synchronize the read/write/open/close calls while using 2.1 to avoid the concurrency issue. The flush is probably following a write while the readByte is coming from read(byte b). The bugs existed in rxtx for a long time. I assume changes in the JVM and the presence of multicore systems exposed the issues. -- Trent Jarvi tjarvi at qbang.org From kjetilos at gmail.com Fri Sep 4 06:33:33 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 14:33:33 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <7a803d460909040533n1caf240y8168477a578bc45c@mail.gmail.com> Den 4. september 2009 14.00 skrev Trent Jarvi f?lgende: > > > On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > >> Hi >> >> We are using RXTX version 2.1.7 actively and lately we are having some >> issues with the RXTX library crashing. We are running a windows xp >> system with multiple COM ports where each COM port have a serial >> device connected. Lately we have increased the amount of signaling >> done over the COM ports and we are experiencing several odd crashes. I >> tried to search the mailinglist for something similar but was unable >> to find anything. At one time the RXTX crashed in the >> gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the >> gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack >> traces if someone is interested in having a look. Has anyone seen the >> same crashes? and does anyone know what can cause such crash? >> >> >> Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x7d0d] >> J ?gnu.io.RXTXPort.nativeDrain(Z)Z >> J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > >> Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x9c55] >> C ?[rxtxSerial.dll+0xa05e] >> J ?gnu.io.RXTXPort.readByte()I >> J ?gnu.io.RXTXPort$SerialInputStream.read()I > > > RXTX 2.1-7 has concurrency issues that will show upon multicore systems. > These should be resolved in the 2.2 pre release. ?A user application could > synchronize the read/write/open/close calls while using 2.1 to avoid the > concurrency issue. > > The flush is probably following a write while the readByte is coming from > read(byte b). > > The bugs existed in rxtx for a long time. ?I assume changes in the JVM and > the presence of multicore systems exposed the issues. > Ok, so we should look more into using a newer version of RXTX. The current version from the webpage is 2.2pre2, what is the stability status of this version. Is it good enough for use in a production environment? -- Kjetil ?ster?s From martinezrodolfo at gmail.com Fri Sep 4 13:39:57 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Fri, 4 Sep 2009 15:09:57 -0430 Subject: [Rxtx] Problem with data available event Message-ID: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Hello list members. I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a serial port USB adapter to communicate with an electronical inmunoassay analyzer. The program works porperly with one model of the analyzer series. It defines a protocol which every message sent should be replied with an ACK in order to continue with the communication. Now we are trying to communicate with another model of the same brand and series wich in theory should be much of the same of what was previously done. Unfortunately, that is not the case. The problem with this connection is that it never fires the Data Available serial port event. Is like if nothing was being received in the input stream. The following code always prints zero when the equipment should be transmitting. ----------------------- beginning of sample code ---------------------------------- SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", 10000); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); int len = 0; byte[] readBuffer = new byte[8]; while (true) { len = in.read(readBuffer); System.out.println(len); writer.writeACK(); // writing ACK to analyzer } ----------------------- end of sample code ------------------------------------------ We know that the analyzer is transmitting because HyperTerminal does shows the proper output. In fact, after running the above code and connecting via Hyperterminal all data is received in one block. Is like the data sent from the analyzer is being held somewhere in the way. Sniffing at the serial port, noticed that IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this helps to find what might be wrong or not, but here they are: On Hyperterminal: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 XonLimit:80 XoffLimit:200 On Java: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 XonLimit:0 XoffLimit:0 Thanks in advance for your help. Rodolfo M From ilkka at myller.com Sat Sep 5 04:36:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 5 Sep 2009 13:36:27 +0300 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <121198EE-65A4-463B-ACC7-29FFB9855B2C@myller.com> Hi Rodolfo, By default RXTX does not enable any flow control for the serial port. Please check what flow control you have active in HyperTerminal when you are able to receive data and then use the same flow control with RXTX serial port: serialPort.setFlowControlMode(int flowcontrol); Possible flowcontrol flags are (from SerialPort class) FLOWCONTROL_NONE FLOWCONTROL_RTSCTS_IN FLOWCONTROL_RTSCTS_OUT FLOWCONTROL_XONXOFF_IN FLOWCONTROL_XONXOFF_OUT For example, you can try enabling RTS/CTS hardware flow control. Note the bitwise OR operator ' | ': serialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Also if your device requires RTS/CTS flow control make sure you have fully connected serial cable (not just RX, TX, GND for example, but also RTS, CTS, DTR). One thing you might want to check is the state of DTR (Data Terminal Ready). Some devices wait for the DTR signal before they send any data. You can enable or disable DTR signal (high/low) with: serialPort.setDTR( boolean state ); -- I > Hello list members. > > I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a > serial port USB adapter to communicate with an electronical > inmunoassay analyzer. The program works porperly with one model of the > analyzer series. It defines a protocol which every message sent should > be replied with an ACK in order to continue with the communication. > Now we are trying to communicate with another model of the same brand > and series wich in theory should be much of the same of what was > previously done. Unfortunately, that is not the case. The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. > > ----------------------- beginning of sample code > ---------------------------------- > SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", > 10000); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > InputStream in = serialPort.getInputStream(); > OutputStream out = serialPort.getOutputStream(); > > int len = 0; > byte[] readBuffer = new byte[8]; > while (true) { > len = in.read(readBuffer); > System.out.println(len); > > writer.writeACK(); // writing ACK to analyzer > } > ----------------------- end of sample code > ------------------------------------------ > > We know that the analyzer is transmitting because HyperTerminal does > shows the proper output. In fact, after running the above code and > connecting via Hyperterminal all data is received in one block. Is > like the data sent from the analyzer is being held somewhere in the > way. Sniffing at the serial port, noticed that > IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this > helps to find what might be wrong or not, but here they are: > > On Hyperterminal: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 > XonLimit:80 XoffLimit:200 > > On Java: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 > XonLimit:0 XoffLimit:0 > > > Thanks in advance for your help. > Rodolfo M > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.weber99 at gmx.net Sun Sep 6 13:51:12 2009 From: karl.weber99 at gmx.net (Karl Weber) Date: Sun, 6 Sep 2009 21:51:12 +0200 Subject: [Rxtx] Cannot create lock file Message-ID: <200909062151.12228.karl.weber99@gmx.net> Hi, I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an opensuse repository as well as from the homepage of the rxtx project. I have already added the user to the group uucp, however, it does not have any effect. What else do I have to do to make it work? (It does work with user root, though.) The error message is: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL Thanks in advance, Karl From tjarvi at qbang.org Sun Sep 6 13:51:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 6 Sep 2009 13:51:42 -0600 (MDT) Subject: [Rxtx] Cannot create lock file In-Reply-To: <200909062151.12228.karl.weber99@gmx.net> References: <200909062151.12228.karl.weber99@gmx.net> Message-ID: On Sun, 6 Sep 2009, Karl Weber wrote: > Hi, > > I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an > opensuse repository as well as from the homepage of the rxtx project. > > I have already added the user to the group uucp, however, it does not have > any effect. What else do I have to do to make it work? (It does work with > user root, though.) > > The error message is: > > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to > create lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > > Thanks in advance, Karl Look at the group that owns /var/lock with ls -ld /var/lock The following should work as a user when they are in the correct group: touch /var/lock/test && rm -f /var/lock/test -- Trent Jarvi tjarvi at qbang.org From Luca.Catoni at sysdat.it Mon Sep 7 06:32:42 2009 From: Luca.Catoni at sysdat.it (Luca Catoni) Date: Mon, 7 Sep 2009 14:32:42 +0200 Subject: [Rxtx] time-out implementation Message-ID: I need to implement a simple timer class to manage time-out in my RS-232 serial communication with a remote device using the rxtx library. The functions that the timer should have are start(), and reset() and start() method must throw an exception (TimeoutException) when it expires. I am not an expert in concurrent programming and I do not have much knowledge on threads. myTimer.setExpirationTime(myvalue); ? public void serialEvent(SerialPortEvent event) { if (event.getEventType() == SerialPortEvent.OUTPUT_BUFFER_EMPTY) { // transmission ? out.write(?); try{ myTimer.start(); }catch(TimeoutException te){ myTimer.reset(); ? } ? if (event.getEventType() == SerialPortEvent.DATA_AVAILABLE) { // receiving in.read(?); if (mycondition){ myTimer.stop();//ok, timer NOT expired myTimer.reset();//now I can call start() method again in //transmission to restart my timer when I //have to transmit next data } Can anyone help me to implement the class MyTimer? thanks in advance. -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Mon Sep 7 06:49:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Mon, 7 Sep 2009 18:19:24 +0530 Subject: [Rxtx] 2.2Pre + MacMini+ Deadlock while second time port Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E22FB6F@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, Please find the updated code (close call was commented by mistake). This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From michael.erskine at ketech.com Mon Sep 7 09:13:03 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 7 Sep 2009 16:13:03 +0100 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Rodolfo Mart?nez > Subject: [Rxtx] Problem with data available event > The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. Hi Rodolfo, The sample code you provided doesn't implement or register any event listeners. Regards, Michael Erskine. From martinezrodolfo at gmail.com Mon Sep 7 10:21:22 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Mon, 7 Sep 2009 11:51:22 -0430 Subject: [Rxtx] Problem with data available event In-Reply-To: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> Message-ID: <30eacee0909070921l7f285765ue2c661963183fd2b@mail.gmail.com> On Mon, Sep 7, 2009 at 10:43 AM, Michael Erskine wrote: > Hi Rodolfo, > The sample code you provided doesn't implement or register any event listeners. > > Regards, > Michael Erskine. Hi Michael, I didn't write the event listeners declaration on the sample code for simplicity, but I do implement them on my real code. I should have mentioned it on the sample code anyway... my bad. I haven't had access to the device I'm trying to connect, but tomorrow will. And hope that with the explanation of Ilkka Myller will succeed this time. Thanks for your attention. Rodolfo M From ajmas at sympatico.ca Mon Sep 7 16:58:13 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 7 Sep 2009 18:58:13 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" I noticed in the page you posted posted you indicated that you patched two files. Did you submit the changes to Jarvi, so they could be included in the main code branch? Andr? From tjarvi at qbang.org Mon Sep 7 16:57:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Sep 2009 16:57:53 -0600 (MDT) Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On Mon, 7 Sep 2009, Andre-John Mas wrote: > > On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > >> Sorry, my rudeness was not intentional (a typo). >> Lets try again.. ;) >> >> "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > I noticed in the page you posted posted you indicated that you patched two > files. Did you submit the changes to Jarvi, so they could be included in the > main code branch? > Hi Andr? Ilkka is working with us to get changes in. I'm not sure about those two patches which may already be in CVS. I'll let him answer that. I've given him write access to CVS and asked him to cc the list non whitespace changes when they are ready. Right now he is asking questions off the list regarding cleaning up the Mac and w32 build files. -- Trent Jarvi tjarvi at qbang.org From nsp25 at cornell.edu Mon Sep 7 21:17:45 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Mon, 7 Sep 2009 23:17:45 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: (Sorry if this is a double post, but I sent my original message without subscribing, and since this is an urgent problem, I thought I'd resend after subscribing to bypass the moderator limbo zone) Hi all, I've asked my question on StackOverflow already, so rather than copy-paste the question here, I'd like to redirect you there . Short version, I am no longer able to receive anything over RS-232 with RXTX, but other programs work fine. I'm definitely sending things, because when I connect with a different program, all the responses to the commands I sent via RXTX arrive all at once. Everything was fine in the spring, so what could have happened? Windows update? -Nate -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.j.tandy at warwick.ac.uk Tue Sep 8 01:30:48 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Tue, 8 Sep 2009 08:30:48 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> OK, so: 1. It worked in spring but has stopped doing so and 2. The data all arrives at once when you start hyperterminal. Is it possible you're using a different serial cable to connect to the device, compared to the one you were using in spring? If so, the issue might be hardware flow control - that is, your device might be buffering data because it can't transmit it until your computer sets 'DTR' or 'RTS' or something like that. One way of bypassing hardware flow control is by using cables which cross over certain wires so that the right signals are always being sent; it's possible your old cable had these connections but your current cable doesn't have them. If you can find the old cable, you could put it back in and see if that fixes things? 2009/9/8 Nathaniel S. Parsons : > (Sorry if this is a double post, but I sent my original message without > subscribing, and since this is an urgent problem, I thought I'd resend after > subscribing to bypass the moderator limbo zone) > > Hi all, > > I've asked my question on StackOverflow already, so rather than copy-paste > the question here, I'd like to redirect you there. > > Short version, I am no longer able to receive anything over RS-232 with > RXTX, but other programs work fine. I'm definitely sending things, because > when I connect with a different program, all the responses to the commands I > sent via RXTX arrive all at once. > > Everything was fine in the spring, so what could have happened? Windows > update? > > -Nate > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Tue Sep 8 01:50:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 8 Sep 2009 10:50:33 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <111FEC9A-26BA-435C-BABC-314C7E4F23E5@myller.com> Hi all, Patches applied to the 2.1.7 binaries distributed by Robert Harder (http://iharder.sourceforge.net/current/java/ ) are already in the 2.2. Actually in 2.2 the issue with integer types handling seems to be fixed even more extensively than that single patch to 2.1.7 originally did. And yes, Trent has granted me CVS commit access. Thank you. First thing I'm going to focus on is the code quality and clean up: unused variables, invalid pointer usage etc.. Most of this just causing compile warnings - some harmless and some have potential for causing runtime problems. Instead of just blindly committing new changes to CVS, I've been discussing with Trent about the way things have been done in the RXTX CVS before. (how to handle white space patches, what needs to be discussed with the list first, proper locations for new files/ directories/subprojects, "the way things are done in RXTX"). But patches are coming and bugs will be fixed. I hope everyone will continue to submit the bugs they discover to this mailing list. Most important thing is to provide enough info (code;) so that the issue can be duplicated and eventually fixed. -- I > > > On Mon, 7 Sep 2009, Andre-John Mas wrote: >> >> I noticed in the page you posted posted you indicated that you >> patched two files. Did you submit the changes to Jarvi, so they >> could be included in the main code branch? >> > > Ilkka is working with us to get changes in. I'm not sure about > those two patches which may already be in CVS. I'll let him answer > that. > > I've given him write access to CVS and asked him to cc the list non > whitespace changes when they are ready. Right now he is asking > questions off the list regarding cleaning up the Mac and w32 build > files. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 15:35:19 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 17:35:19 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: Thanks for the response. I'll try to get to the electronics store tomorrow to get more serial cables, even if it isn't the problem. I am using a different serial cable than I was in the spring. It's actually a Male/Female cable with a female-female adapter since the old cables aren't around anymore. The hardware's manual says nothing except to use a "Straight cable" but I figured that if it worked in HyperTerminal, it should work in RXTX, right? Anyways, I've also noticed some things that are different between HyperTerminal, RXTX, and a separate program I found that communicates with the device (but doesn't do what I want, which is why I'm rolling my own program) HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and DTR indicators are green Other program - not sure what settings it thinks it's using, but only SPM's RTS indicator is green RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators are on. >From Serial Port Monitor's help files (paraphrased): the indicators display the state of the serial control lines RTS - Request To Send CTS - Clear To Send DTR - Data Terminal Ready Could this be related to the problem? -Nate On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > OK, so: > > 1. It worked in spring but has stopped doing so and > 2. The data all arrives at once when you start hyperterminal. > > Is it possible you're using a different serial cable to connect to the > device, compared to the one you were using in spring? > > If so, the issue might be hardware flow control - that is, your device > might be buffering data because it can't transmit it until your > computer sets 'DTR' or 'RTS' or something like that. > > One way of bypassing hardware flow control is by using cables which > cross over certain wires so that the right signals are always being > sent; it's possible your old cable had these connections but your > current cable doesn't have them. If you can find the old cable, you > could put it back in and see if that fixes things? > > > 2009/9/8 Nathaniel S. Parsons : > > (Sorry if this is a double post, but I sent my original message without > > subscribing, and since this is an urgent problem, I thought I'd resend > after > > subscribing to bypass the moderator limbo zone) > > > > Hi all, > > > > I've asked my question on StackOverflow already, so rather than > copy-paste > > the question here, I'd like to redirect you there. > > > > Short version, I am no longer able to receive anything over RS-232 with > > RXTX, but other programs work fine. I'm definitely sending things, > because > > when I connect with a different program, all the responses to the > commands I > > sent via RXTX arrive all at once. > > > > Everything was fine in the spring, so what could have happened? Windows > > update? > > > > -Nate > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 18:57:58 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 20:57:58 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: I added a call to setRTS() but nothing changed in Serial Port Monitor, no matter what the argument was. Is this a bug, or did I call the wrong function? I tried to find the c code behind this function, and I think I found it in rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong to me. Am I looking at the right function or is the problem somewhere else? -Nate On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons wrote: > Thanks for the response. I'll try to get to the electronics store tomorrow > to get more serial cables, even if it isn't the problem. > > I am using a different serial cable than I was in the spring. It's actually > a Male/Female cable with a female-female adapter since the old cables aren't > around anymore. The hardware's manual says nothing except to use a "Straight > cable" but I figured that if it worked in HyperTerminal, it should work in > RXTX, right? > > Anyways, I've also noticed some things that are different between > HyperTerminal, RXTX, and a separate program I found that communicates with > the device (but doesn't do what I want, which is why I'm rolling my own > program) > > HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and > DTR indicators are green > Other program - not sure what settings it thinks it's using, but only SPM's > RTS indicator is green > RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators > are on. > > From Serial Port Monitor's help files (paraphrased): the indicators display > the state of the serial control lines > > RTS - Request To Send > CTS - Clear To Send > DTR - Data Terminal Ready > > Could this be related to the problem? > > -Nate > > > On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > >> OK, so: >> >> 1. It worked in spring but has stopped doing so and >> 2. The data all arrives at once when you start hyperterminal. >> >> Is it possible you're using a different serial cable to connect to the >> device, compared to the one you were using in spring? >> >> If so, the issue might be hardware flow control - that is, your device >> might be buffering data because it can't transmit it until your >> computer sets 'DTR' or 'RTS' or something like that. >> >> One way of bypassing hardware flow control is by using cables which >> cross over certain wires so that the right signals are always being >> sent; it's possible your old cable had these connections but your >> current cable doesn't have them. If you can find the old cable, you >> could put it back in and see if that fixes things? >> >> >> 2009/9/8 Nathaniel S. Parsons : >> > (Sorry if this is a double post, but I sent my original message without >> > subscribing, and since this is an urgent problem, I thought I'd resend >> after >> > subscribing to bypass the moderator limbo zone) >> > >> > Hi all, >> > >> > I've asked my question on StackOverflow already, so rather than >> copy-paste >> > the question here, I'd like to redirect you there. >> > >> > Short version, I am no longer able to receive anything over RS-232 with >> > RXTX, but other programs work fine. I'm definitely sending things, >> because >> > when I connect with a different program, all the responses to the >> commands I >> > sent via RXTX arrive all at once. >> > >> > Everything was fine in the spring, so what could have happened? Windows >> > update? >> > >> > -Nate >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Tue Sep 8 21:54:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 21:54:26 -0600 (MDT) Subject: [Rxtx] rxtx is moving to the clouds Message-ID: rxtx is moving onto a cloud server. You may notice short outages as things move around. So far the following is done. http://rxtx.qbang.org (will redirect rxtx.org there for 2.2) http://bugzilla.qbang.org (bugs) The mail-list is tomorrow night. CVS and FTP will be last. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 8 22:03:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 22:03:26 -0600 (MDT) Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: On Tue, 8 Sep 2009, Nathaniel S. Parsons wrote: > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? Hi Nathaniel, That depends upon what you are running. WinCE is for embedded windows. The Windows source is in src/termios.c (called from src/SerialImp.c). -- Trent Jarvi tjarvi at qbang.org From m.j.tandy at warwick.ac.uk Wed Sep 9 03:27:10 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 10:27:10 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> I had a similar problem a while ago - hardware that would work with Hyperterminal but not with Rxtx. I don't know if this is a bug in RxTx or not - I tried to find where in the RxTx source code those functions are actually implemented - I got as far as the ioctl function in termios.c, where the TIOCMSET case sets the MSR byte in the termios struct, but I can't figure out where that gets written to the dcb struct's fDtrControl dword. It could be a bug, or it could just be me missing something. In any case, at the time I had this problem I wasn't equipped to debug RxTx so instead I created a special cable to satisfy the hardware's flow control while leaving the data connection straight through. Here's how I connected it: At the female end of the cable (i.e. the hardware I was connecting to) I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. I connected the ground and data pins straight through - that is, pin 5 female end to pin 5 male end, pin 2 female end to pin 2 male end, pin 3 female end to pin 3 male end. Anyway, using that cable bypassed the hardware's flow control, and got RxTx working just as well as HyperTerminal - although I slowed down my communication to make sure I didn't encounter a situation where the flow control would have come into effect, as I had bypassed it! Hope that helps. 2009/9/9 Nathaniel S. Parsons : > I added a call to setRTS() but nothing changed in Serial Port Monitor, no > matter what the argument was. Is this a bug, or did I call the wrong > function? > > I tried to find the c code behind this function, and I think I found it in > rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong > to me. Am I looking at the right function or is the problem somewhere else? > > -Nate > > On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > wrote: >> >> Thanks for the response. I'll try to get to the electronics store tomorrow >> to get more serial cables, even if it isn't the problem. >> >> I am using a different serial cable than I was in the spring. It's >> actually a Male/Female cable with a female-female adapter since the old >> cables aren't around anymore. The hardware's manual says nothing except to >> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >> should work in RXTX, right? >> >> Anyways, I've also noticed some things that are different between >> HyperTerminal, RXTX, and a separate program I found that communicates with >> the device (but doesn't do what I want, which is why I'm rolling my own >> program) >> >> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >> DTR indicators are green >> Other program - not sure what settings it thinks it's using, but only >> SPM's RTS indicator is green >> RXTX - no matter what flow control I set, only SPM's CTS and DTR >> indicators are on. >> >> From Serial Port Monitor's help files (paraphrased): the indicators >> display the state of the serial control lines >> >> RTS - Request To Send >> CTS - Clear To Send >> DTR - Data Terminal Ready >> >> Could this be related to the problem? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> wrote: >>> >>> OK, so: >>> >>> 1. It worked in spring but has stopped doing so and >>> 2. The data all arrives at once when you start hyperterminal. >>> >>> Is it possible you're using a different serial cable to connect to the >>> device, compared to the one you were using in spring? >>> >>> If so, the issue might be hardware flow control - that is, your device >>> might be buffering data because it can't transmit it until your >>> computer sets 'DTR' or 'RTS' or something like that. >>> >>> One way of bypassing hardware flow control is by using cables which >>> cross over certain wires so that the right signals are always being >>> sent; it's possible your old cable had these connections but your >>> current cable doesn't have them. If you can find the old cable, you >>> could put it back in and see if that fixes things? >>> >>> >>> 2009/9/8 Nathaniel S. Parsons : >>> > (Sorry if this is a double post, but I sent my original message without >>> > subscribing, and since this is an urgent problem, I thought I'd resend >>> > after >>> > subscribing to bypass the moderator limbo zone) >>> > >>> > Hi all, >>> > >>> > I've asked my question on StackOverflow already, so rather than >>> > copy-paste >>> > the question here, I'd like to redirect you there. >>> > >>> > Short version, I am no longer able to receive anything over RS-232 with >>> > RXTX, but other programs work fine. I'm definitely sending things, >>> > because >>> > when I connect with a different program, all the responses to the >>> > commands I >>> > sent via RXTX arrive all at once. >>> > >>> > Everything was fine in the spring, so what could have happened? Windows >>> > update? >>> > >>> > -Nate >>> > >>> > _______________________________________________ >>> > Rxtx mailing list >>> > Rxtx at qbang.org >>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>> > >>> > >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Wed Sep 9 03:54:45 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 12:54:45 +0300 Subject: [Rxtx] Xcode 3.x project available in CVS Message-ID: Hi everyone, I've just committed Apple Xcode 3.x (preferably 3.2) compatible project to CVS. The project can be used to develop and build Mac OS X 10.5+ compatible Universal Binary JNI library and RXTXcomm.jar. It's does not have dependencies to existing Autotools based build scripts - only standard Xcode installation is required. The older Xcode 2.x project is still there, but please note that it's not compatible with newer Xcode versions due to its dependency to deprecated Jam build system. The new project is available in rxtx-devel/MACOSX_IDE/Xcode3 How to get the source code from CVS: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Latest Xcode can be downloaded from Apple: http://developer.apple.com/technology/xcode.html -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 05:07:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 14:07:05 +0300 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: Nathaniel, I agree with Michael that your issue is probably with incorrect hardware flow control (RTS/CTS + possibly DTR/DSR). With RXTX you can do things manually, automatically or by mixing both ways. RXTX is "low-level" enough to let developer make those decisions. Which is proper. Automatic hardware flow-control: If you want to do automatic RTS/CTS flow control in both directions (from and to PC) you must set: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Note that you must combine flow control flags with bitwise OR ( ' | ' ) Manual: If you want to bypass all flow controls signals, or handle them manually you must set: setFlowControlMode( SerialPort.FLOWCONTROL_NONE ); In manual mode, you must manually handle controlling signals from PC and reading flow control signals from by the device: RTS - Request To Send -- setRTS() method can used to set this CTS - Clear To Send -- isCTS() method can be used to read this For example, it is entirely possible to manually implement normal RTS/ CTS flow control with RXTX without relying on low-level automatic implementation. Mixed: You can also configure serial port to handle RTS/CTS automatically in only one direction, then you must set one of: setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN ); or setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_OUT ); Then you can either ignore or implement manually the flow control scheme in the other direction. DTR and DSR: These are not officially flow control signals, but might affect external devices (disable, standby etc.). Use and meaning of these depends on the device. DTR - Data Terminal Ready -- setDTR() method DSR - Data Set Ready -- setDSR() method CTS/RTS standards: Please note that there are two standard ways RTS/CTS flow control is done (depends on the device): asymmetric (RS-232) symmetric (RS-232-E / TIA-232-E) For more info see: http://en.wikipedia.org/wiki/RS232#RTS.2FCTS_handshaking Some devices may even use RTS/CTS to some other non-standard purpose. With those devices, enabling automatic RTS/CTS could cause very strange behaviour as they clearly require manual control of CTS/RTS. ---- As far as I know, RXTX properly controls all these signals all the way to actual RS232 pins - unless there is a new platform incompatibility bug that I'm not aware of;) Mostly it's just wrong combination and/or usage of these additional signals that cause problems receiving or sending. And the only solution is to really *know* how your device wants these signals handled - and then code your RXTX application accordingly. Creating non-standard cable is not the right solution in my opinion. Unfortunately some applications (like HyperTerminal for example) might hit more or less accidentally to the right combination of RTS/CTS/DTR/ DSR usage and make RXTX look bad in comparison. While all RXTX does by default is - well - nothing. It gives full control the developer. -- I > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port >> Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I >> found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't >> look wrong >> to me. Am I looking at the right function or is the problem >> somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > > >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store >>> tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since >>> the old >>> cables aren't around anymore. The hardware's manual says nothing >>> except to >>> use a "Straight cable" but I figured that if it worked in >>> HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that >>> communicates with >>> the device (but doesn't do what I want, which is why I'm rolling >>> my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's >>> RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but >>> only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >> > >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect >>>> to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your >>>> device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>>> (Sorry if this is a double post, but I sent my original message >>>>> without >>>>> subscribing, and since this is an urgent problem, I thought I'd >>>>> resend >>>>> after >>>>> subscribing to bypass the moderator limbo zone) >>>>> >>>>> Hi all, >>>>> >>>>> I've asked my question on StackOverflow already, so rather than >>>>> copy-paste >>>>> the question here, I'd like to redirect you there. >>>>> >>>>> Short version, I am no longer able to receive anything over >>>>> RS-232 with >>>>> RXTX, but other programs work fine. I'm definitely sending things, >>>>> because >>>>> when I connect with a different program, all the responses to the >>>>> commands I >>>>> sent via RXTX arrive all at once. >>>>> >>>>> Everything was fine in the spring, so what could have happened? >>>>> Windows >>>>> update? >>>>> >>>>> -Nate >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 9 06:11:11 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 9 Sep 2009 15:11:11 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings Message-ID: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Hi, Summary: Patch includes multiple minor code quality improvements and also fixes one possible null pointer segfault on Mac. After this patch, compilation on Mac OS X is error/warning free even with gcc -Wall setting. I'll submit more code quality patches later that focus more on linux/ win/java. Fixes: Code quality: - First level parentheses around assignment used as while-loop truth value - Some printf formats not a string literals and including no format arguments Invalid null pointer usage: - Mac: IOMasterPort was called with (int)NULL which does not always resolve to segfault safe value. Corrected to use MACH_PORT_NULL instead. Patch: The patch is against CVS head (@2009/09/09). Attached patch file is in 'cvs diff -up' format. I'll commit this patch to the CVS later this week if there are no objections. Feel free to comment. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090909.patch Type: application/octet-stream Size: 1966 bytes Desc: not available URL: From m.j.tandy at warwick.ac.uk Wed Sep 9 06:57:55 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 9 Sep 2009 13:57:55 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> Message-ID: <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> OK, I just ran a test with my copy of RxTx and the following program: import gnu.io.*; public class SerialTest { public static void main(String[] args) { try { CommPortIdentifier portid = CommPortIdentifier.getPortIdentifier("COM9"); SerialPort serialPort = (SerialPort)portid.open("Serial port DTR/RTS test", 1000); serialPort.setSerialPortParams(4800, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.disableReceiveTimeout(); for (int i=0 ; i<60 ; i++) { serialPort.setDTR(true); serialPort.setRTS(true); Thread.sleep(1000); serialPort.setDTR(false); serialPort.setRTS(false); Thread.sleep(1000); } } catch (Exception e) { e.printStackTrace(); System.exit(1); } System.exit(0); } } I'm using a USB-serial converter (Prolific PL-2303) and I used a multimeter to check that my DTR and RTS pins were both toggling, and they were - between +7 and -6.4 volts. In other words, on the computer I'm using at the moment, with the version of RxTx I'm using at the moment, setDTR and setRTS both seem to work fine. I don't know if it's worth it for you to perform the same test. I gather there are several different configurations for hardware flow control, (DTR/DSR handshaking as well as RTS/CTS handshaking, handshaking for half-duplex operation, and similar) so the cable that worked for me might still be worth a try. 2009/9/9 Michael Tandy : > I had a similar problem a while ago - hardware that would work with > Hyperterminal but not with Rxtx. > > I don't know if this is a bug in RxTx or not - I tried to find where > in the RxTx source code those functions are actually implemented - I > got as far as the ioctl function in termios.c, where the TIOCMSET case > sets the MSR byte in the termios struct, but I can't figure out where > that gets written to the dcb struct's fDtrControl dword. It could be a > bug, or it could just be me missing something. > > In any case, at the time I had this problem I wasn't equipped to debug > RxTx so instead I created a special cable to satisfy the hardware's > flow control while leaving the data connection straight through. > Here's how I connected it: > > At the female end of the cable (i.e. the hardware I was connecting to) > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > I connected the ground and data pins straight through - that is, pin 5 > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > 3 female end to pin 3 male end. > > Anyway, using that cable bypassed the hardware's flow control, and got > RxTx working just as well as HyperTerminal - although I slowed down my > communication to make sure I didn't encounter a situation where the > flow control would have come into effect, as I had bypassed it! > > Hope that helps. > > > 2009/9/9 Nathaniel S. Parsons : >> I added a call to setRTS() but nothing changed in Serial Port Monitor, no >> matter what the argument was. Is this a bug, or did I call the wrong >> function? >> >> I tried to find the c code behind this function, and I think I found it in >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong >> to me. Am I looking at the right function or is the problem somewhere else? >> >> -Nate >> >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons >> wrote: >>> >>> Thanks for the response. I'll try to get to the electronics store tomorrow >>> to get more serial cables, even if it isn't the problem. >>> >>> I am using a different serial cable than I was in the spring. It's >>> actually a Male/Female cable with a female-female adapter since the old >>> cables aren't around anymore. The hardware's manual says nothing except to >>> use a "Straight cable" but I figured that if it worked in HyperTerminal, it >>> should work in RXTX, right? >>> >>> Anyways, I've also noticed some things that are different between >>> HyperTerminal, RXTX, and a separate program I found that communicates with >>> the device (but doesn't do what I want, which is why I'm rolling my own >>> program) >>> >>> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and >>> DTR indicators are green >>> Other program - not sure what settings it thinks it's using, but only >>> SPM's RTS indicator is green >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR >>> indicators are on. >>> >>> From Serial Port Monitor's help files (paraphrased): the indicators >>> display the state of the serial control lines >>> >>> RTS - Request To Send >>> CTS - Clear To Send >>> DTR - Data Terminal Ready >>> >>> Could this be related to the problem? >>> >>> -Nate >>> >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy >>> wrote: >>>> >>>> OK, so: >>>> >>>> 1. It worked in spring but has stopped doing so and >>>> 2. The data all arrives at once when you start hyperterminal. >>>> >>>> Is it possible you're using a different serial cable to connect to the >>>> device, compared to the one you were using in spring? >>>> >>>> If so, the issue might be hardware flow control - that is, your device >>>> might be buffering data because it can't transmit it until your >>>> computer sets 'DTR' or 'RTS' or something like that. >>>> >>>> One way of bypassing hardware flow control is by using cables which >>>> cross over certain wires so that the right signals are always being >>>> sent; it's possible your old cable had these connections but your >>>> current cable doesn't have them. If you can find the old cable, you >>>> could put it back in and see if that fixes things? >>>> >>>> >>>> 2009/9/8 Nathaniel S. Parsons : >>>> > (Sorry if this is a double post, but I sent my original message without >>>> > subscribing, and since this is an urgent problem, I thought I'd resend >>>> > after >>>> > subscribing to bypass the moderator limbo zone) >>>> > >>>> > Hi all, >>>> > >>>> > I've asked my question on StackOverflow already, so rather than >>>> > copy-paste >>>> > the question here, I'd like to redirect you there. >>>> > >>>> > Short version, I am no longer able to receive anything over RS-232 with >>>> > RXTX, but other programs work fine. I'm definitely sending things, >>>> > because >>>> > when I connect with a different program, all the responses to the >>>> > commands I >>>> > sent via RXTX arrive all at once. >>>> > >>>> > Everything was fine in the spring, so what could have happened? Windows >>>> > update? >>>> > >>>> > -Nate >>>> > >>>> > _______________________________________________ >>>> > Rxtx mailing list >>>> > Rxtx at qbang.org >>>> > http://mailman.qbang.org/mailman/listinfo/rxtx >>>> > >>>> > >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > From david at attglobal.net Wed Sep 9 09:17:27 2009 From: david at attglobal.net (David Schmidt) Date: Wed, 09 Sep 2009 11:17:27 -0400 Subject: [Rxtx] 2.2 Release plans Message-ID: <4AA7C707.5060802@attglobal.net> I'm holding off releasing an update to my project (adtpro.sourceforge.net) to support OSX Snow Leopard because I'd like to ship an "official" build of rxtx 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for toggling a port off). CVS is looking great on OSX - thanks to all who have been hard at work on that. I wish there were just one more update - Pre3? :-) My question... If I wanted to make a release in, say, a week... would it pay to wait for rxtx, or should I plan to build and ship a local build of 2.2 out of CVS myself? - David Schmidt From tjarvi at qbang.org Wed Sep 9 19:14:29 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:14:29 -0600 (MDT) Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: On Wed, 9 Sep 2009, Ilkka Myller wrote: > Hi, > > Summary: > > Patch includes multiple minor code quality improvements and also fixes one > possible null pointer segfault on Mac. > After this patch, compilation on Mac OS X is error/warning free even with gcc > -Wall setting. > I'll submit more code quality patches later that focus more on > linux/win/java. > > Fixes: > > Code quality: > - First level parentheses around assignment used as while-loop truth value > - Some printf formats not a string literals and including no format arguments > > Invalid null pointer usage: > - Mac: IOMasterPort was called with (int)NULL which does not always resolve > to segfault safe value. Corrected to use MACH_PORT_NULL instead. > > Patch: > > The patch is against CVS head (@2009/09/09). > Attached patch file is in 'cvs diff -up' format. > > I'll commit this patch to the CVS later this week if there are no objections. > Feel free to comment. > These ifdefs can go. If you like I can remove them when you are done. #ifdef DEBUG_MW mexErrMsgTxt( msg ); #else They are just printf like debug messages for use in an environment in which I could not get directly to stderr/stdout. I don't think anyone uses them anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Sep 9 19:17:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Sep 2009 19:17:43 -0600 (MDT) Subject: [Rxtx] 2.2 Release plans In-Reply-To: <4AA7C707.5060802@attglobal.net> References: <4AA7C707.5060802@attglobal.net> Message-ID: On Wed, 9 Sep 2009, David Schmidt wrote: > I'm holding off releasing an update to my project (adtpro.sourceforge.net) to > support OSX Snow Leopard because I'd like to ship an "official" build of rxtx > 2.2. (I wouldn't mind shipping 2.2Pre2, but it lacks a critical fix for > toggling a port off). CVS is looking great on OSX - thanks to all who have > been hard at work on that. I wish there were just one more update - Pre3? > :-) > > My question... If I wanted to make a release in, say, a week... would it pay > to wait for rxtx, or should I plan to build and ship a local build of 2.2 out > of CVS myself? > Hi David, I would suggest planning on shipping a local build in a 1 week timeframe. We could put another prerelease up but there are still fixes coming in. -- Trent Jarvi tjarvi at qbang.org From ilkka at myller.com Wed Sep 9 23:07:34 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:07:34 +0300 Subject: [Rxtx] [Patch] Code quality and compiler warnings In-Reply-To: References: <6A4194F3-7521-47E9-BE9F-0E2824E1CBE1@myller.com> Message-ID: <04A41559-598C-4B6E-821A-DA90CB6228E7@myller.com> Patch (im-20090909.patch) has been committed to the CVS. Trent: I'll include DEBUG_MW cleanup to my next patch. > > On Wed, 9 Sep 2009, Ilkka Myller wrote: > >> Hi, >> >> Summary: >> >> Patch includes multiple minor code quality improvements and also >> fixes one possible null pointer segfault on Mac. >> After this patch, compilation on Mac OS X is error/warning free >> even with gcc -Wall setting. >> I'll submit more code quality patches later that focus more on >> linux/win/java. >> >> Fixes: >> >> Code quality: >> - First level parentheses around assignment used as while-loop >> truth value >> - Some printf formats not a string literals and including no format >> arguments >> >> Invalid null pointer usage: >> - Mac: IOMasterPort was called with (int)NULL which does not always >> resolve to segfault safe value. Corrected to use MACH_PORT_NULL >> instead. >> >> Patch: >> >> The patch is against CVS head (@2009/09/09). >> Attached patch file is in 'cvs diff -up' format. >> >> I'll commit this patch to the CVS later this week if there are no >> objections. >> Feel free to comment. >> > > These ifdefs can go. If you like I can remove them when you are done. > > #ifdef DEBUG_MW > mexErrMsgTxt( msg ); > #else > > They are just printf like debug messages for use in an environment > in which I could not get directly to stderr/stdout. I don't think > anyone uses them anymore. > > -- > Trent Jarvi > tjarvi at qbang.org From ilkka at myller.com Wed Sep 9 23:35:13 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 08:35:13 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= Message-ID: Hi, Summary: Patch fixes compiling on Linux distributions/kernels that dont ship with linux/utsrelease.h header and therefore have no UTS_RELEASE defined. Usually this applies only to newer distributions and/or kernels - for example Ubuntu 9.04. Fixes: The UTS_RELEASE vs uname checking in initialization functions is now done only in debug build and only when UTS_RELEASE is actually defined. Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910.patch Type: application/octet-stream Size: 9542 bytes Desc: not available URL: From ilkka at myller.com Thu Sep 10 06:43:02 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 15:43:02 +0300 Subject: [Rxtx] =?iso-8859-1?q?=5BPatch=5D=A0Fix_build_on_Linux_systems_wi?= =?iso-8859-1?q?thout_UTS=5FRELEASE?= In-Reply-To: References: Message-ID: Patch has been committed to CVS. > Hi, > > Summary: > > Patch fixes compiling on Linux distributions/kernels that dont ship > with linux/utsrelease.h header and therefore have no UTS_RELEASE > defined. > Usually this applies only to newer distributions and/or kernels - > for example Ubuntu 9.04. > > Fixes: > > The UTS_RELEASE vs uname checking in initialization functions is now > done only in debug build and only when UTS_RELEASE is actually > defined. > > Patch: > > The patch is against CVS head (@2009/09/10). > Attached patch file is in 'cvs diff -up' format. > > > Thanks, > > -- > I > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Thu Sep 10 09:08:01 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 18:08:01 +0300 Subject: [Rxtx] [Patch] Remove unused MathWorks MATLAB DEBUG_MW ifdefs Message-ID: <6DB57DB1-A47E-4435-9CD6-212B671A2849@myller.com> Summary: Patch removes unused MathWorks MATLAB timing debug ifdefs (DEBUG_MW). This is a request from Trent. Fixes: - Removes DEBUG_MW definitions - Removes unused mex....() function definitions - Corrects DEBUG_TIMING to work properly without mexPrintf (with Mac OS X specific format string fixes included) - Removes unused/duplicate timeval struct and DEBUG_TIMING definitions from SerialImp.c and SerialImp.h - Corrects fprintf call in SerialImp.cpp Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910b.patch Type: application/octet-stream Size: 9841 bytes Desc: not available URL: From Kapil_Gupta at hcl.in Thu Sep 10 10:25:29 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 10 Sep 2009 21:55:29 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, I am getting some problem with RXTX on macintosh (reading some data from the device attached to the usb port through usb to serial mechanism). I used the RXTX 2.1.7 then I got PortInUseException but after using 2.2pre it worked fine. But it works only for the first time, it hangs in the second time while opening the port. Please find the attached code. This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Thu Sep 10 13:00:14 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 22:00:14 +0300 Subject: [Rxtx] [Patch] Implement return value checking to file I/O calls Message-ID: Summary: The return value of some functions should always be used. For example, it is dangerous to not check the return value of a write(), read(), open(), fscanf() calls. This patch fixes such occurences in RXTX code. For example: unchecked read() call could result in later - and often seemingly unrelated - segfault due to undefined read buffer contents. After this patch the Linux build process is error/warning free even with gcc -Wall -Werror. Fixes: - Implemented return value checking to file I/O calls in SerialImp.c:fhs_lock(), uucp_lock() and is_device_locked() functions. - Added error recovery for fuserImp.c fscanf() calls. Patch: The patch is against CVS head (@2009/09/10). Attached patch file is in 'cvs diff -up' format. -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090910c.patch Type: application/octet-stream Size: 3370 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Thu Sep 10 13:08:05 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 10 Sep 2009 22:08:05 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> Hi Kapil, I believe this issue has been fixed in CVS version, but still exists in 2.2pre2 available from RXTX wiki. For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html As you've seen from the recent patches announced on this list, we are working very hard to make a new 2.2pre(?) release available. Meanwhile, you can compile your own RXTX binaries from CVS source. On Mac it should be exceptionally easy with new Xcode 3.x project files. Thank you for your patience, -- I > > I am getting some problem with RXTX on macintosh (reading some data > from the device attached to the usb port through usb to serial > mechanism). I used the RXTX 2.1.7 then I got PortInUseException but > after using 2.2pre it worked fine. But it works only for the first > time, it hangs in the second time while opening the port. From ilkka at myller.com Fri Sep 11 04:07:22 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 13:07:22 +0300 Subject: [Rxtx] [Patch] Windows build improvements (MinGW32, MSVC and LCC) Message-ID: <81D06766-8D51-485A-B2A2-624C8EA690BA@myller.com> Summary: Fixes various compiler warnings with Windows builds. Removes unused code blocks from compilation. After this patch the Windows build process is error/warning free with MinGW32, MSVC and LCC compilers - even with -Wall enabled. Does not fix: Latest LCC compiler version still fails even after this patch due to compiler trap error. Trap error does not specify source code location - it fails outputting SerialImp.obj binary. Compiling SerialImp.c without binary output works. Could this be a bug in LCC? Tested with clean RXTX source, latest standard LCC installation and with both Windows Vista SP1 x86 and Windows XP SP3 x86. Patch: The patch is against CVS (@2009/09/11). Attached patch file is in 'cvs diff -up' format. Thanks, -- I -------------- next part -------------- A non-text attachment was scrubbed... Name: im-20090911.patch Type: application/octet-stream Size: 6673 bytes Desc: not available URL: From Kapil_Gupta at hcl.in Fri Sep 11 08:21:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Fri, 11 Sep 2009 19:51:24 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Ilkka, I tried getting the source code from the CVS but we could not able to do so, the CVS was not responding. Then we downloaded the 2.2 pre2 code and made the changes that are described in http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html but the problem didn't change. First time the device responds well and the second time it hangs. Did you see the code that we have sent to you, so that you can suggest if we are doing something wrong in our code. Again attaching if you have deleted that. Please suggest (does the CVS code can help rather using the patch provided by you?). Thanks, Kapil -----Original Message----- From: Ilkka Myller [mailto:ilkka at myller.com] Sent: Friday, September 11, 2009 12:38 AM To: Kapil Gupta Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Hi Kapil, I believe this issue has been fixed in CVS version, but still exists in 2.2pre2 available from RXTX wiki. For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html As you've seen from the recent patches announced on this list, we are working very hard to make a new 2.2pre(?) release available. Meanwhile, you can compile your own RXTX binaries from CVS source. On Mac it should be exceptionally easy with new Xcode 3.x project files. Thank you for your patience, -- I > > I am getting some problem with RXTX on macintosh (reading some data > from the device attached to the usb port through usb to serial > mechanism). I used the RXTX 2.1.7 then I got PortInUseException but > after using 2.2pre it worked fine. But it works only for the first > time, it hangs in the second time while opening the port. DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Fri Sep 11 09:33:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 18:33:33 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Hi Kapil, For CVS: Instructions at the old rxtx website are incorrect. Trent updated them, but to a wrong server address "qgang.org" -- the correct server is "qbang.org". Please follow instructions from rxtx wiki: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code About testing your code: When I have time (maybe this weekend), I'll test your code using Mac OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. What USB serial port you are using with your Mac? Something with FTDI chip? or maybe Prolific? What adapter driver version you are using? Just asking, so I can test with the same configuration. Meanwhile I suggest you: - Make sure you have the latest USB Serial adapter drivers, so we can eliminate past issues with those. - Check that you are not having multiple copies of librxtxSerial.jnilib (possibly different versions) in your java library path (=trouble;) - Check for any USB Serial adaptors kernel extension error messages in system log after testing your software (use Console.app to browse logs) -- I Kapil Gupta kirjoitti 11.9.2009 kello 17.21: > Hi Ilkka, > > I tried getting the source code from the CVS but we could not able > to do so, the CVS was not responding. Then we downloaded the 2.2 > pre2 code and made the changes that are described in http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html > but the problem didn't change. First time the device responds well > and the second time it hangs. > > Did you see the code that we have sent to you, so that you can > suggest if we are doing something wrong in our code. Again attaching > if you have deleted that. Please suggest (does the CVS code can help > rather using the patch provided by you?). > > Thanks, > Kapil > > -----Original Message----- > From: Ilkka Myller [mailto:ilkka at myller.com] > Sent: Friday, September 11, 2009 12:38 AM > To: Kapil Gupta > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second > time port open > > Hi Kapil, > > I believe this issue has been fixed in CVS version, but still exists > in 2.2pre2 available from RXTX wiki. > > For more details: http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html > > As you've seen from the recent patches announced on this list, we are > working very hard to make a new 2.2pre(?) release available. > > Meanwhile, you can compile your own RXTX binaries from CVS source. On > Mac it should be exceptionally easy with new Xcode 3.x project files. > > > Thank you for your patience, > > > -- > I > > >> >> I am getting some problem with RXTX on macintosh (reading some data >> from the device attached to the usb port through usb to serial >> mechanism). I used the RXTX 2.1.7 then I got PortInUseException but >> after using 2.2pre it worked fine. But it works only for the first >> time, it hangs in the second time while opening the port. > > > DISCLAIMER: > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential > and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of this > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > ----------------------------------------------------------------------------------------------------------------------- > From ilkka at myller.com Fri Sep 11 11:51:13 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 11 Sep 2009 20:51:13 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Message-ID: <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> Ok, I debugged your code on Mac using USB-RS232 adapter + loopback adapter. My findings: there are no issues with RXTX in your code -- there are issues with threading and synchronization. Primary issue: you essentially lock the JVM main thread to 100% CPU usage with infinite loop: while (!processCompleted) { ; } Now.. I'm going to give you a bad advice, mostly because you have bigger threading issues there.. but we must continue somehow: A quick remedy to previous is: while (!processCompleted) { Thread.yield(); } Thread yielding gives other threads atleast a chance to run (and to processCompleted boolean to actually update in main thread context). What happens next is that your main-thread is allowed to continue and proceeds to closeConnection() call it otherwise would never reach. After that, connection closes properly.. main() method continues to "System.out.println(result);" and proceeds to exit JVM.. .. except.. Secondary issue: Exit is one thing JVM cant do since you have left a Timer thread hanging without proper closing in getData() method. Cancel it (uncomment that line) - and your code completes main() to a clean JVM exit. So, my advice to you is to focus on fixing threading, timers and synchronization. Design those well and everything works. Multithreading, done well or not, will not usually confuse RXTX ... but your own code might not be so lucky. -- I > > When I have time (maybe this weekend), I'll test your code using Mac > OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. >> >> Did you see the code that we have sent to you, so that you can >> suggest if we are doing something wrong in our code. Again >> attaching if you have deleted that. Please suggest (does the CVS >> code can help rather using the patch provided by you?). -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 11 15:19:26 2009 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 11 Sep 2009 17:19:26 -0400 Subject: [Rxtx] Can't run my Netbeans/Java s/w on a MAC Message-ID: <4AAABEDE.7020508@howardz.com> An HTML attachment was scrubbed... URL: From ilkka at myller.com Fri Sep 11 15:41:10 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 12 Sep 2009 00:41:10 +0300 Subject: [Rxtx] Can't run my Netbeans/Java s/w on a MAC In-Reply-To: <4AAABEDE.7020508@howardz.com> References: <4AAABEDE.7020508@howardz.com> Message-ID: <35D4BD73-B8CC-4DEE-A846-8858C9C9EBC7@myller.com> Hi, The bug that causes the segfault (invalid memory access) has been fixed (in CVS): http://mailman.qbang.org/pipermail/rxtx/2009-February/4810504.html Next prerelease is coming (soon I hope), but the the 2.2pre2 fails when reopening the serial port on Mac OS X. -- I > > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] Jar > version = RXTX-2.2pre1 > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] native > lib Version = RXTX-2.2pre2 > 9/6/09 3:45:59 PM [0x0-0x26b26b].com.apple.JarLauncher[6160] Invalid > memory access of location 0x12b5e3938 rip=0x12955012f > 9/6/09 3:46:00 PM ReportCrash[6164] Saved crash report for java > [6162] version 13.0.0 (13.0.0) to /Users/myles/Library/Logs/ > DiagnosticReports/java_2009-09-06-154600_myles-PowerBook-PP-108.crash -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Fri Sep 11 20:15:31 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 11 Sep 2009 20:15:31 -0600 (MDT) Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> Message-ID: On Fri, 11 Sep 2009, Ilkka Myller wrote: > Hi Kapil, > > For CVS: > > Instructions at the old rxtx website are incorrect. Trent updated them, but > to a wrong server address "qgang.org" -- the correct server is "qbang.org". > Please follow instructions from rxtx wiki: > > http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code The old website has been corrected. -- Trent Jarvi tjarvi at qbang.org From dvd at newfoundmarket.com Sat Sep 12 11:49:48 2009 From: dvd at newfoundmarket.com (DVD) Date: Sat, 12 Sep 2009 13:49:48 -0400 Subject: [Rxtx] RXTX on linux hang Message-ID: <4AABDF3C.2040908@newfoundmarket.com> Hello: I just did a fresh install of RXTZ on both Ubuntu and centos, Java version 6, update 12 I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with the Usage example from your website Two way communcation with the serial port I used the computer's serial port /dev/ttyS0, with UART 16550A the program simply hang. The port was opened and both input/output streamed were opened but the writing/reading are not working. Any help would be appreciated. I tried this program on windows and it worked fine. Thanks From ilkka at myller.com Sat Sep 12 15:31:26 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sun, 13 Sep 2009 00:31:26 +0300 Subject: [Rxtx] RXTX on linux hang In-Reply-To: <4AABDF3C.2040908@newfoundmarket.com> References: <4AABDF3C.2040908@newfoundmarket.com> Message-ID: Hi, It's very hard to say what could be wrong without more details. Can you tell me more about your Linux setup: - Output of: uname -a - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your test code running) - Output of: cat /proc/tty/driver/serial - Are you you testing with root privileges - What kind of device you are communicating with (or just a loopback dongle)? - Does your device expect some specific flow control and/or specific state of DTR/DSR signals? - Have you tried configuring those flow controls and other RS232 signals in your test code? Did they work? - Do other simple terminal programs work (easiest to try: screen /dev/ ttyS0 )? - What is the CPU usage (use 'top' or some other process monitor your like) of your test software when it "hangs"? I can try to duplicate your issue on Ubuntu 9.04 (both x86 and x86_64), Centos 5 (x86) and Debian 5.0 (x86). I'd prefer to test with the same kind of system you have.. Thanks, -- I > > I just did a fresh install of RXTZ on both Ubuntu and centos, Java > version 6, update 12 > I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with > the Usage example from > your website > > Two way communcation with the serial port > > > I used the computer's serial port /dev/ttyS0, with UART 16550A > > the program simply hang. The port was opened and both input/output > streamed were opened > but the writing/reading are not working. > > Any help would be appreciated. I tried this program on windows and > it worked fine. From dvd at newfoundmarket.com Sat Sep 12 21:20:14 2009 From: dvd at newfoundmarket.com (DVD) Date: Sat, 12 Sep 2009 23:20:14 -0400 Subject: [Rxtx] RXTX on linux hang In-Reply-To: References: <4AABDF3C.2040908@newfoundmarket.com> Message-ID: <4AAC64EE.7050904@newfoundmarket.com> Thank you very much for the steps. It is pin out problem. Again, Thanks. Ilkka Myller wrote: > Hi, > > It's very hard to say what could be wrong without more details. > Can you tell me more about your Linux setup: > > - Output of: uname -a > - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your > test code running) > - Output of: cat /proc/tty/driver/serial > - Are you you testing with root privileges > - What kind of device you are communicating with (or just a loopback > dongle)? > - Does your device expect some specific flow control and/or specific > state of DTR/DSR signals? > - Have you tried configuring those flow controls and other RS232 > signals in your test code? Did they work? > - Do other simple terminal programs work (easiest to try: screen > /dev/ttyS0 )? > - What is the CPU usage (use 'top' or some other process monitor your > like) of your test software when it "hangs"? > > > I can try to duplicate your issue on Ubuntu 9.04 (both x86 and > x86_64), Centos 5 (x86) and Debian 5.0 (x86). > I'd prefer to test with the same kind of system you have.. > > > Thanks, > > -- > I > > >> >> I just did a fresh install of RXTZ on both Ubuntu and centos, Java >> version 6, update 12 >> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with >> the Usage example from >> your website >> >> Two way communcation with the serial port >> >> >> >> I used the computer's serial port /dev/ttyS0, with UART 16550A >> >> the program simply hang. The port was opened and both input/output >> streamed were opened >> but the writing/reading are not working. >> >> Any help would be appreciated. I tried this program on windows and >> it worked fine. > From tjarvi at qbang.org Sun Sep 13 12:06:33 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Sep 2009 12:06:33 -0600 (MDT) Subject: [Rxtx] RXTX on linux hang In-Reply-To: <4AAC64EE.7050904@newfoundmarket.com> References: <4AABDF3C.2040908@newfoundmarket.com> <4AAC64EE.7050904@newfoundmarket.com> Message-ID: Hi, Would it be possible to get a short paragraph from you describing the pinout problem and how you discovered it? We can add that to the wiki to help others get past the problem faster next time. On Sat, 12 Sep 2009, DVD wrote: > Thank you very much for the steps. It is pin out problem. > Again, Thanks. > > Ilkka Myller wrote: >> Hi, >> >> It's very hard to say what could be wrong without more details. >> Can you tell me more about your Linux setup: >> >> - Output of: uname -a >> - Output of: stty -a -F /dev/ttyS0 (if possible: with and without your test >> code running) >> - Output of: cat /proc/tty/driver/serial >> - Are you you testing with root privileges >> - What kind of device you are communicating with (or just a loopback >> dongle)? >> - Does your device expect some specific flow control and/or specific state >> of DTR/DSR signals? >> - Have you tried configuring those flow controls and other RS232 signals in >> your test code? Did they work? >> - Do other simple terminal programs work (easiest to try: screen /dev/ttyS0 >> )? >> - What is the CPU usage (use 'top' or some other process monitor your like) >> of your test software when it "hangs"? >> >> >> I can try to duplicate your issue on Ubuntu 9.04 (both x86 and x86_64), >> Centos 5 (x86) and Debian 5.0 (x86). >> I'd prefer to test with the same kind of system you have.. >> >> >> Thanks, >> >> -- >> I >> >> >>> >>> I just did a fresh install of RXTZ on both Ubuntu and centos, Java version >>> 6, update 12 >>> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with the >>> Usage example from >>> your website >>> >>> Two way communcation with the serial port >>> >>> >>> I used the computer's serial port /dev/ttyS0, with UART 16550A >>> >>> the program simply hang. The port was opened and both input/output >>> streamed were opened >>> but the writing/reading are not working. >>> >>> Any help would be appreciated. I tried this program on windows and it >>> worked fine. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dvd at newfoundmarket.com Sun Sep 13 19:18:08 2009 From: dvd at newfoundmarket.com (DVD) Date: Sun, 13 Sep 2009 21:18:08 -0400 Subject: [Rxtx] RXTX on linux hang In-Reply-To: References: <4AABDF3C.2040908@newfoundmarket.com> <4AAC64EE.7050904@newfoundmarket.com> Message-ID: <4AAD99D0.3030206@newfoundmarket.com> Hello, It was a human mistake during wiring and was discovered after staring at it for a while :-). Nothing technical worth mentioning. Thanks Trent Jarvi wrote: > > Hi, > > Would it be possible to get a short paragraph from you describing the > pinout problem and how you discovered it? We can add that to the wiki > to help others get past the problem faster next time. > > On Sat, 12 Sep 2009, DVD wrote: > >> Thank you very much for the steps. It is pin out problem. >> Again, Thanks. >> >> Ilkka Myller wrote: >>> Hi, >>> >>> It's very hard to say what could be wrong without more details. >>> Can you tell me more about your Linux setup: >>> >>> - Output of: uname -a >>> - Output of: stty -a -F /dev/ttyS0 (if possible: with and without >>> your test code running) >>> - Output of: cat /proc/tty/driver/serial >>> - Are you you testing with root privileges >>> - What kind of device you are communicating with (or just a loopback >>> dongle)? >>> - Does your device expect some specific flow control and/or specific >>> state of DTR/DSR signals? >>> - Have you tried configuring those flow controls and other RS232 >>> signals in your test code? Did they work? >>> - Do other simple terminal programs work (easiest to try: screen >>> /dev/ttyS0 )? >>> - What is the CPU usage (use 'top' or some other process monitor >>> your like) of your test software when it "hangs"? >>> >>> >>> I can try to duplicate your issue on Ubuntu 9.04 (both x86 and >>> x86_64), Centos 5 (x86) and Debian 5.0 (x86). >>> I'd prefer to test with the same kind of system you have.. >>> >>> >>> Thanks, >>> >>> -- >>> I >>> >>> >>>> >>>> I just did a fresh install of RXTZ on both Ubuntu and centos, Java >>>> version 6, update 12 >>>> I tried both rxtx version 2.1.7 binaries and 2.2pre2 binaries with >>>> the Usage example from >>>> your website >>>> >>>> Two way communcation with the serial port >>>> >>>> >>>> I used the computer's serial port /dev/ttyS0, with UART 16550A >>>> >>>> the program simply hang. The port was opened and both input/output >>>> streamed were opened >>>> but the writing/reading are not working. >>>> >>>> Any help would be appreciated. I tried this program on windows and >>>> it worked fine. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From Kapil_Gupta at hcl.in Mon Sep 14 08:37:23 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Mon, 14 Sep 2009 20:07:23 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B30A4F25D@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Ilkka, We have done that also, but no success. I am attaching the code, please check the updated code also. We are not using any FTDI/Prolific chip set. We are using TI chip set. We are having only one copy of JNI lib. No Error in console for kernel driver. Warm Regards, Kapil From: Ilkka Myller [mailto:ilkka at myller.com] Sent: Friday, September 11, 2009 11:21 PM To: Kapil Gupta Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Ok, I debugged your code on Mac using USB-RS232 adapter + loopback adapter. My findings: there are no issues with RXTX in your code -- there are issues with threading and synchronization. Primary issue: you essentially lock the JVM main thread to 100% CPU usage with infinite loop: while (!processCompleted) { ; } Now.. I'm going to give you a bad advice, mostly because you have bigger threading issues there.. but we must continue somehow: A quick remedy to previous is: while (!processCompleted) { Thread.yield(); } Thread yielding gives other threads atleast a chance to run (and to processCompleted boolean to actually update in main thread context). What happens next is that your main-thread is allowed to continue and proceeds to closeConnection() call it otherwise would never reach. After that, connection closes properly.. main() method continues to "System.out.println(result);" and proceeds to exit JVM.. .. except.. Secondary issue: Exit is one thing JVM cant do since you have left a Timer thread hanging without proper closing in getData() method. Cancel it (uncomment that line) - and your code completes main() to a clean JVM exit. So, my advice to you is to focus on fixing threading, timers and synchronization. Design those well and everything works. Multithreading, done well or not, will not usually confuse RXTX ... but your own code might not be so lucky. -- I When I have time (maybe this weekend), I'll test your code using Mac OS X 10.6.1 and USB Serial Adapter attached to serial loopback dongle. Did you see the code that we have sent to you, so that you can suggest if we are doing something wrong in our code. Again attaching if you have deleted that. Please suggest (does the CVS code can help rather using the patch provided by you?). DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10005 bytes Desc: SerialDeviceHandler.java URL: From ilkka at myller.com Mon Sep 14 17:03:55 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 15 Sep 2009 02:03:55 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B30A4F25D@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E380F95@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <54FD890A-E498-43ED-B901-433135CEE90C@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E3DAB34@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> <96D3C773-C016-47E5-9E83-5AD8648A7E77@myller.com> <7FBEFEA1-7C8C-4BB3-B54E-7D8814B594F9@myller.com> <91958FAFDBC0ED4F8600DF946EA3CE3F4B30A4F25D@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <989B2FAA-5E5A-4F47-AF23-04CE1A6A20F7@myller.com> Kapil, You did not fix the primary issue. Your while() loop still blocks the main thread and the code is not working for the same reasons I stated before. .. but .. I created a demonstration code, which does not try to duplicate the behaviour of your code, but instead demonstrates few concepts: 1. Safe opening of the serial port with full error checking 2. Proper handling of text encoding using Reader/Writer. If your protocol handles plaintext, I recommend you use encoding capable streams. 3. Asynchronous multi-threaded receiving and transmitting (separate thread for each, with their own packet (=string, in this case) queues) 4. Handling serial port data-available events without blocking the event handler (=event only signals async. receiver) 5. Controlling access to serial port in multithreaded app using ReentrantLock (still allows embedded transmit->receive, as demonstrated) 6. Signaling thread from other thread with wait() -> notify() (demonstrated in serial event handling) The code does one simple thing: sends a US-ASCII encoded string to serial port with CR+LF and expects the same line to be received back. I used simple loopback adapter hardware to test this. Normally, doing just this simple task does not require such heavy multi-threading async. receiver/transmitter structures, but I created them to demonstrate various multi-threading concepts, and how they can be used with RXTX. The code is not perfect, it's still a quick hack to demonstrate few things. For example, it lacks proper error handling and propagation in async. receiver/transmitter. However, this code is "profiler clean". It's threads are mostly idle waiting other threads or actual events from RXTX. No thread is blocked in high CPU-% loops etc. when receiving or sending. This also scales nicely to run on multiple CPU's with modern JVM's. When implementing commercial protocol handlers this is how things should always be. Doing "while(someBoolean) {}" is generally not the correct method to sync things. -- I > Hi Ilkka, > > We have done that also, but no success. I am attaching the code, > please check the updated code also. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 11656 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail4ng at gmail.com Tue Sep 15 03:02:48 2009 From: mail4ng at gmail.com (Daniel Weinand) Date: Tue, 15 Sep 2009 11:02:48 +0200 Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby Message-ID: <4AAF5838.7080707@gmail.com> Hello, i'm using RXTX with a USB to Serial Adapter on Linux and Windows machines. Everything works great. but now i have a problem on a Vista machine with standby mode. after the machine wakes up i'll get an infinite error loop: Error 0x5 at ..\src\termios.c(2712): Access Denied Error 0x5 at ..\src\termios.c(517): Access Denied ... and so on. My Application runs as a windows service and so it tries to enumerate and connect to the port directly after it wakes up. but the Port is blocked until i restart the whole machine and everything starts from 0. i'm using rxtx 2.2pre2 is this a known problem and how to solve this? From stefan.frings at vodafone.com Tue Sep 15 09:08:04 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Tue, 15 Sep 2009 17:08:04 +0200 Subject: [Rxtx] Reloading C library after USB error Message-ID: Hello, I wrote a web application that uses rxtxcomm to communicate to USB devices through virtual serial ports (e.g. /dev/ttyUSB0) on Linux. When I unplug a device while the port is open and then plug it back, I cannot access it anymore. I need to kill -9 Tomcat and then restart it. I think that I need to re-load the C library. Another problem occurs when I plug in an USB device after my web application has started. In this case, the new device cannot be accessed through rxtxcomm. Again, I assume that I need to relaod the C library. I am not able to shut-down my web application after these two errors occur. Tomcat reports, that the shut-down failed. How can I reload the C library without hardly killing my running Tomcat? -------------- next part -------------- An HTML attachment was scrubbed... URL: From petter.real at gmail.com Tue Sep 15 14:32:29 2009 From: petter.real at gmail.com (Petter Rafael Villa Real) Date: Tue, 15 Sep 2009 17:32:29 -0300 Subject: [Rxtx] RXTX on Ubuntu 9.04 with lock in /var/lock/LCK..ttyS0. Message-ID: Hi, I always used the RXTX to read/write the serial successfully on Windows. But now I need to use Linux Ubuntu 9.04, I changed to COM1, with on Windows, to /dev/ttyS0, the reading starts on the terminal but the RXTX will warn that you must release the lock of the serial. In the RXTX documentation is indicated add uucd User groups and / or lock to resolve this problem, but in Ubuntu do not have this group. Does anyone have experience with Ubuntu to help me? P.S.: sorry for my bad english. Thank you. -- -- --------------------------------------------------------------------- Petter R. Villa Real Silva -- Desenvolvedor Web Viamais Desenvolvimento Web Powered by Java/Oracle PHP/MySQL Web Alocation e Hosting - PHP/JSP --------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at attglobal.net Tue Sep 15 19:36:38 2009 From: david at attglobal.net (David Schmidt) Date: Tue, 15 Sep 2009 21:36:38 -0400 Subject: [Rxtx] 2.2 Release plans In-Reply-To: References: <4AA7C707.5060802@attglobal.net> Message-ID: <4AB04126.5070002@attglobal.net> Trent Jarvi wrote: > On Wed, 9 Sep 2009, David Schmidt wrote: > >> I'm holding off releasing an update to my project >> (adtpro.sourceforge.net) to support OSX Snow Leopard because I'd like >> to ship an "official" build of rxtx 2.2. (I wouldn't mind shipping >> 2.2Pre2, but it lacks a critical fix for toggling a port off). CVS is >> looking great on OSX - thanks to all who have been hard at work on >> that. I wish there were just one more update - Pre3? :-) >> >> My question... If I wanted to make a release in, say, a week... would >> it pay to wait for rxtx, or should I plan to build and ship a local >> build of 2.2 out of CVS myself? >> > > Hi David, > > I would suggest planning on shipping a local build in a 1 week > timeframe. We could put another prerelease up but there are still fixes > coming in. Thanks for the encouragement, guys. I'm having a little less luck now - building for OSX on an Intel box runs on a PPC box, but not on Intel... weird. I guess I'll wait a bit more. :-) - David From david at attglobal.net Tue Sep 15 19:51:28 2009 From: david at attglobal.net (David Schmidt) Date: Tue, 15 Sep 2009 21:51:28 -0400 Subject: [Rxtx] FTDI chipset speed - much slower? Message-ID: <4AB044A0.10509@attglobal.net> I am finding that my app is behaving really slowly when I'm connecting with a FTDI chipset equipped USB-serial adapter. I'm finding my app to be "fast" when I use native UART ports, Prolific or Keyspan USB adapters. But my FTDI adapters are remarkably, astonishingly slower when sending data (in my case, this means moving data from the DE-9 to the USB end) than any other method. I mean it is maybe 1/5 the "normal" speed I see from every other method. CPU remains calm on the USB (i.e. Mac or PC) end of the adapter. It's just really slow. Data moving in the other direction seems to run at full speed. I'm suspecting I'm doing something wrong along the way that is reacting badly with this chipset. My initial, lazy question, before exposing my code to the harsh light of day: is there anything obvious I might be doing wrong to this chipset to make it run so slowly? Has anyone else run into the same problem? - David From tjarvi at qbang.org Tue Sep 15 20:03:51 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 15 Sep 2009 20:03:51 -0600 (MDT) Subject: [Rxtx] FTDI chipset speed - much slower? In-Reply-To: <4AB044A0.10509@attglobal.net> References: <4AB044A0.10509@attglobal.net> Message-ID: On Tue, 15 Sep 2009, David Schmidt wrote: > I am finding that my app is behaving really slowly when I'm connecting > with a FTDI chipset equipped USB-serial adapter. I'm finding my app to be > "fast" when I use native UART ports, Prolific or Keyspan USB adapters. > But my FTDI adapters are remarkably, astonishingly slower when sending > data (in my case, this means moving data from the DE-9 to the USB end) > than any other method. I mean it is maybe 1/5 the "normal" speed I see > from every other method. CPU remains calm on the USB (i.e. Mac or PC) end > of the adapter. It's just really slow. Data moving in the other > direction seems to run at full speed. > > I'm suspecting I'm doing something wrong along the way that is reacting > badly with this chipset. My initial, lazy question, before exposing my > code to the harsh light of day: is there anything obvious I might be doing > wrong to this chipset to make it run so slowly? Has anyone else run into > the same problem? > Given that rxtx does not treat usb special, it may be something to do with the nature of USB serial dongles. One suspicion I've had is that the event loop is competing for bandwidth by trying to check the UART status which is on the other side of the USB line. 1/5th is fairly significant. This is just writing/reading? How large are the transfers? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 15 20:07:12 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 15 Sep 2009 20:07:12 -0600 (MDT) Subject: [Rxtx] Reloading C library after USB error In-Reply-To: References: Message-ID: On Tue, 15 Sep 2009, Frings, Stefan, VF-DE wrote: > Hello, > ? > I wrote a web application that uses rxtxcomm to communicate to USB > devices through virtual serial ports (e.g. /dev/ttyUSB0) on Linux. > ? > When I unplug a device while the port is open and then plug it back, I > cannot access it anymore. I need to kill -9 Tomcat and then restart it. I > think that?I need to re-load the C library. > ? > Another problem occurs when I plug in an USB device after my web > application has started. In this case, the new device cannot be accessed > through rxtxcomm. Again, I assume that I need to relaod the C library. > ? > I am not able to shut-down my web application after these two errors > occur.? Tomcat reports, that the shut-down failed. > ? > How can I reload the C library without hardly killing my running Tomcat? > > I don't think the native library needs to shut down but the code does not expect the file descriptor to go invalid. Duct taping the USB dongle isnt always an option but thats how rxtx is currently coded. read/write and the event loop could all fail at any time and need to shut down the port. This code is not in place. We don't get USB events through the API so it has to be done by checking errors. The library also needs the ability to rescan the available ports. When it was written, you had to shut down the computer to remove a serial port so rescanning wasnt a concern. If those two fixes are made, you will be able to exit tomcat gracefully. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 15 20:08:54 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 15 Sep 2009 20:08:54 -0600 (MDT) Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby In-Reply-To: <4AAF5838.7080707@gmail.com> References: <4AAF5838.7080707@gmail.com> Message-ID: On Tue, 15 Sep 2009, Daniel Weinand wrote: > Hello, > > i'm using RXTX with a USB to Serial Adapter on Linux and Windows machines. > Everything works great. > but now i have a problem on a Vista machine with standby mode. after the > machine wakes up i'll get an infinite error loop: > > > Error 0x5 at ..\src\termios.c(2712): Access Denied > Error 0x5 at ..\src\termios.c(517): Access Denied > ... > > and so on. > > My Application runs as a windows service and so it tries to enumerate and > connect to the port directly > after it wakes up. but the Port is blocked until i restart the whole > machine and everything starts from 0. > > i'm using rxtx 2.2pre2 > > is this a known problem and how to solve this? It is a known problem. The kernel driver isnt restoring the fd. See the previous post for what is required prior to being able to handle it in your code. -- Trent Jarvi tjarvi at qbang.org From nsp25 at cornell.edu Tue Sep 15 20:50:11 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 15 Sep 2009 22:50:11 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> <302aa0340909090227x4b4c6140q9bde8cfdda2e9e6a@mail.gmail.com> <302aa0340909090557t645ec2e0mac06a550a7e418d8@mail.gmail.com> Message-ID: Thank you very much Ikka and Mike. Sorry I didn't get back sooner, but your emails got buried in my inbox, and I didn't see them until yesterday, or get to try it out until today. The following body of the connect method worked (same serial cable): SerialPort port = (SerialPort) CommPortIdentifier.getPortIdentifier("COM1").open("", 1000); port.setSerialPortParams(baud, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); // Never tried this before, it was just one or the other port.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT); port.setRTS(true); // Seems to work when flow control is set right port.setDTR(false); // Just in case port.disableReceiveTimeout(); However, I noticed what could be a bug in RXTX for Windows XP. While running PortMon, I discovered what could be problems in the (attached) log file, namely INVALID_PARAMETER return codes for IOCTL_SERIAL_CLR_RTS happens, I believe) and twice for IOCTL_SERIAL_SET_RTS. The log is nearly identical each time I connect, with the same failures. What's the easiest way I can run RXTX in debug mode? I have visual studio 2008, if that helps. If anyone wants to help me track this (new?) bug down, I can provide whatever computer information you ask for. -Nate On Wed, Sep 9, 2009 at 8:57 AM, Michael Tandy wrote: > OK, I just ran a test with my copy of RxTx and the following program: > > import gnu.io.*; > public class SerialTest { > public static void main(String[] args) { > > try { > CommPortIdentifier portid = > CommPortIdentifier.getPortIdentifier("COM9"); > SerialPort serialPort = (SerialPort)portid.open("Serial > port DTR/RTS test", 1000); > serialPort.setSerialPortParams(4800, > SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > serialPort.disableReceiveTimeout(); > for (int i=0 ; i<60 ; i++) { > serialPort.setDTR(true); > serialPort.setRTS(true); > Thread.sleep(1000); > serialPort.setDTR(false); > serialPort.setRTS(false); > Thread.sleep(1000); > } > } catch (Exception e) { > e.printStackTrace(); > System.exit(1); > } > System.exit(0); > } > } > > I'm using a USB-serial converter (Prolific PL-2303) and I used a > multimeter to check that my DTR and RTS pins were both toggling, and > they were - between +7 and -6.4 volts. > > In other words, on the computer I'm using at the moment, with the > version of RxTx I'm using at the moment, setDTR and setRTS both seem > to work fine. I don't know if it's worth it for you to perform the > same test. > > I gather there are several different configurations for hardware flow > control, (DTR/DSR handshaking as well as RTS/CTS handshaking, > handshaking for half-duplex operation, and similar) so the cable that > worked for me might still be worth a try. > > > 2009/9/9 Michael Tandy : > > I had a similar problem a while ago - hardware that would work with > > Hyperterminal but not with Rxtx. > > > > I don't know if this is a bug in RxTx or not - I tried to find where > > in the RxTx source code those functions are actually implemented - I > > got as far as the ioctl function in termios.c, where the TIOCMSET case > > sets the MSR byte in the termios struct, but I can't figure out where > > that gets written to the dcb struct's fDtrControl dword. It could be a > > bug, or it could just be me missing something. > > > > In any case, at the time I had this problem I wasn't equipped to debug > > RxTx so instead I created a special cable to satisfy the hardware's > > flow control while leaving the data connection straight through. > > Here's how I connected it: > > > > At the female end of the cable (i.e. the hardware I was connecting to) > > I linked DB9 pin 7 to pin 8; and I linked pin 4 to pin 6. > > I connected the ground and data pins straight through - that is, pin 5 > > female end to pin 5 male end, pin 2 female end to pin 2 male end, pin > > 3 female end to pin 3 male end. > > > > Anyway, using that cable bypassed the hardware's flow control, and got > > RxTx working just as well as HyperTerminal - although I slowed down my > > communication to make sure I didn't encounter a situation where the > > flow control would have come into effect, as I had bypassed it! > > > > Hope that helps. > > > > > > 2009/9/9 Nathaniel S. Parsons : > >> I added a call to setRTS() but nothing changed in Serial Port Monitor, > no > >> matter what the argument was. Is this a bug, or did I call the wrong > >> function? > >> > >> I tried to find the c code behind this function, and I think I found it > in > >> rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look > wrong > >> to me. Am I looking at the right function or is the problem somewhere > else? > >> > >> -Nate > >> > >> On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons > > >> wrote: > >>> > >>> Thanks for the response. I'll try to get to the electronics store > tomorrow > >>> to get more serial cables, even if it isn't the problem. > >>> > >>> I am using a different serial cable than I was in the spring. It's > >>> actually a Male/Female cable with a female-female adapter since the old > >>> cables aren't around anymore. The hardware's manual says nothing except > to > >>> use a "Straight cable" but I figured that if it worked in > HyperTerminal, it > >>> should work in RXTX, right? > >>> > >>> Anyways, I've also noticed some things that are different between > >>> HyperTerminal, RXTX, and a separate program I found that communicates > with > >>> the device (but doesn't do what I want, which is why I'm rolling my own > >>> program) > >>> > >>> HyperTerminal - set to no flow control, but Serial Port Monitor's RTS > and > >>> DTR indicators are green > >>> Other program - not sure what settings it thinks it's using, but only > >>> SPM's RTS indicator is green > >>> RXTX - no matter what flow control I set, only SPM's CTS and DTR > >>> indicators are on. > >>> > >>> From Serial Port Monitor's help files (paraphrased): the indicators > >>> display the state of the serial control lines > >>> > >>> RTS - Request To Send > >>> CTS - Clear To Send > >>> DTR - Data Terminal Ready > >>> > >>> Could this be related to the problem? > >>> > >>> -Nate > >>> > >>> On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy > > >>> wrote: > >>>> > >>>> OK, so: > >>>> > >>>> 1. It worked in spring but has stopped doing so and > >>>> 2. The data all arrives at once when you start hyperterminal. > >>>> > >>>> Is it possible you're using a different serial cable to connect to the > >>>> device, compared to the one you were using in spring? > >>>> > >>>> If so, the issue might be hardware flow control - that is, your device > >>>> might be buffering data because it can't transmit it until your > >>>> computer sets 'DTR' or 'RTS' or something like that. > >>>> > >>>> One way of bypassing hardware flow control is by using cables which > >>>> cross over certain wires so that the right signals are always being > >>>> sent; it's possible your old cable had these connections but your > >>>> current cable doesn't have them. If you can find the old cable, you > >>>> could put it back in and see if that fixes things? > >>>> > >>>> > >>>> 2009/9/8 Nathaniel S. Parsons : > >>>> > (Sorry if this is a double post, but I sent my original message > without > >>>> > subscribing, and since this is an urgent problem, I thought I'd > resend > >>>> > after > >>>> > subscribing to bypass the moderator limbo zone) > >>>> > > >>>> > Hi all, > >>>> > > >>>> > I've asked my question on StackOverflow already, so rather than > >>>> > copy-paste > >>>> > the question here, I'd like to redirect you there. > >>>> > > >>>> > Short version, I am no longer able to receive anything over RS-232 > with > >>>> > RXTX, but other programs work fine. I'm definitely sending things, > >>>> > because > >>>> > when I connect with a different program, all the responses to the > >>>> > commands I > >>>> > sent via RXTX arrive all at once. > >>>> > > >>>> > Everything was fine in the spring, so what could have happened? > Windows > >>>> > update? > >>>> > > >>>> > -Nate > >>>> > > >>>> > _______________________________________________ > >>>> > Rxtx mailing list > >>>> > Rxtx at qbang.org > >>>> > http://mailman.qbang.org/mailman/listinfo/rxtx > >>>> > > >>>> > > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at qbang.org > >>>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: connection_log.csv Type: application/octet-stream Size: 9725 bytes Desc: not available URL: From stefan.frings at vodafone.com Wed Sep 16 00:06:52 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Wed, 16 Sep 2009 08:06:52 +0200 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time Message-ID: Hello Daniel Weinand, your proble is surely related to my issue. Im not familiar with Mac OS, but I know that Linux and also Windows normally disconnect all USB devices during standby mode and reconnect them after power-on. RxTx seems to have a problem when a device disappears or appears while the C library is loaded. I think the C library should be changed to re-check the list of available ports whenever the Java application attempts to enumerate or open a port. And when a port disappears while it is open, the library should close it and throw an AlreadyClosedException. I think the Java application should be able to recover itself from temporarily lost devices, and it should also be able to open devices that have been plugged in AFTER the library was loaded. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.frings at vodafone.com Wed Sep 16 00:09:34 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Wed, 16 Sep 2009 08:09:34 +0200 Subject: [Rxtx] Reloading C library after USB error In-Reply-To: References: Message-ID: Hello Trent, Yes, I think the same. The library was obviously not written for USB devices. Is anybody aware of an alternative that works fine with USB / Hotpluggable devices? From stefan.frings at vodafone.com Wed Sep 16 00:12:58 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Wed, 16 Sep 2009 08:12:58 +0200 Subject: [Rxtx] RXTX on Ubuntu 9.04 with lock in /var/lock/LCK..ttyS0 Message-ID: Hello Petter, the serial ports are normally only writeable by root and by users that are in the dialout group. For your case, a solution might be, to add yourself to the dialout group in /etc/group. On my machines, RxTx wporks fine. I am using Ubuntu 8.10 and 9.04 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.frings at vodafone.com Wed Sep 16 00:17:27 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Wed, 16 Sep 2009 08:17:27 +0200 Subject: [Rxtx] FTDI chipset speed - much slower? Message-ID: Hello David, Im not 100% sure, but I highly assume that the delays are produces by the USB communication. USB transfers data in packets and there are large buffers of several hundreds characters, similar to ethernet. There is no real time communication. So when your software thinks that it has sent a character, this was not the case. It was only put into a buffer and will appears at the end of your USB2Serial cable after some time - I assume somewhat around 0,3ms. I noticed the same behavious with different USB2Serial adapters on Linux with plain C programs (not anything around Java and RxTx). -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 16 01:06:41 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 16 Sep 2009 10:06:41 +0300 Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby In-Reply-To: References: <4AAF5838.7080707@gmail.com> Message-ID: <0EB22ACB-0676-44DE-BBD3-A9D38CFD2E88@myller.com> Windows is not my primary platform, but I agree with Trent. I tested this too and noticed that ClearCommError() does not fail because RXTX loses fd (why would it), but because fd seems to no longer exist, or is reused, on kernel side. Resulting in access denied (5) error. Definitely something RXTX has no control of. Also the USB device re-registers itself, causing all it's previous file handles invalidated. After few seconds after waking from sleep, new ones can be created with CreateFile calls - as expected. FTDI chips can be reprogrammed not to do this reconnection cycle on USB sleep (with mprog 3.5 software). I dont know how well Windows follows that setting. Also Windows allows disabling USB power saving on specific USB devices. After those settings, it entirely up to the USB driver to do the right thing. .. which I'm not entirely sure it will - even if it's technically possible to retain fd's over sleep the driver might still be hardwired to reconnect the device on power save events. -- Basicly all these issues are about the fact that someone/something rips off the UART hardware RXTX is controlling. The serial comms features on most operating systems are not equipped to handle this since UART is expected to be integral part of the system. Well, USB has certainly changed that. Now not only the serial device can be unplugged (which is handled properly by protocols etc.) but the actual interface hardware too. Like ripping off the engine from your car while driving. For those reasons this issue is very hard for RXTX or any other serial comms library to handle. We could detect errors from kernel that indicate the UART has vanished and proceed to do automatic reopening of the serial port after some delay at the native lib. But: this has multiple issues, which probably will break user protocols and software. One of those is the fact that reopening the port could toggle its CTS/RTS/DTR/DSR signals causing unexpected trouble on user side. Other one is that we might end up in infinite loop of comm error <-> automatic reopening without notifying rxtx java side. Not elegant. Not proper. -- I'm proposing a following solution: We could implement a method to detect lost UART in event loop at native lib side and introduce a new Java side SerialPortEvent type UART_DISCONNECT. The native lib would send that event in case of error and proceed to automatically close the serial port and clear the invalid handles etc. (reset to fault free state). That would allow user code to gracefully handle these situations, by doing whatever is necessary to restore communications with their protocols etc. Usually that includes opening the serial port and doing some initializations. Those who choose to ignore that event, or not implement any handling for it, can continue to use RXTX as any other serial comms lib. But their software would still tumble and fall on UART disconnects - mostly caused by USB->UART bridges. Atleast, we'd have a method for implementing proper recovery if RXTX user chooses to do so. Beats duct tape+USB dongle combo anytime;) Feedback welcome :) -- I > > > On Tue, 15 Sep 2009, Daniel Weinand wrote: >> >> Error 0x5 at ..\src\termios.c(2712): Access Denied >> Error 0x5 at ..\src\termios.c(517): Access Denied >> ... > > It is a known problem. The kernel driver isnt restoring the fd. > See the previous post for what is required prior to being able to > handle it in your code. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 16 01:18:14 2009 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 16 Sep 2009 10:18:14 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time In-Reply-To: References: Message-ID: I'm referring to my previous post and to my proposal for handling these situations (detection + java side event): In addition to UART_DISCONNECT event I proposed, your suggestion about AlreadyClosedException is great. We'd still have to handle existing "opened port objects" in Java side even after sending the UART_DISCONNECT event. Making them throw AlreadyClosedException would do that elegantly. -- I Frings, Stefan, VF-DE kirjoitti 16.9.2009 kello 9.06: > > And when a port disappears while it is open, the library should > close it and throw an AlreadyClosedException. > > I think the Java application should be able to recover itself from > temporarily lost devices, and it should also be able to open devices > that have been plugged in AFTER the library was loaded. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at attglobal.net Wed Sep 16 03:47:59 2009 From: david at attglobal.net (David Schmidt) Date: Wed, 16 Sep 2009 05:47:59 -0400 Subject: [Rxtx] FTDI chipset speed - much slower? In-Reply-To: References: <4AB044A0.10509@attglobal.net> Message-ID: <4AB0B44F.9060201@attglobal.net> Trent Jarvi wrote: > On Tue, 15 Sep 2009, David Schmidt wrote: >> I'm suspecting I'm doing something wrong along the way that is >> reacting badly with this chipset. My initial, lazy question, before >> exposing my code to the harsh light of day: is there anything obvious >> I might be doing wrong to this chipset to make it run so slowly? Has >> anyone else run into the same problem? > > Given that rxtx does not treat usb special, it may be something to do > with the nature of USB serial dongles. One suspicion I've had is that > the event loop is competing for bandwidth by trying to check the UART > status which is on the other side of the USB line. > > 1/5th is fairly significant. This is just writing/reading? How large > are the transfers? The protocol is a little dance that happens with tiny packets, rapidly sending/receiving (http://adtpro.sourceforge.net/protocol.html#Get). Host sends: 2 bytes: current block number (LSB, MSB) 1 byte: half-block number (2 = bytes 0-255, 1 = bytes 256-511) up to 256 bytes: Half-block, RLE encoded two bytes: CRC (lo) CRC (hi) Apple sends: One byte: acknowledgement Two bytes: current block number (LSB, MSB) One byte: half-block number (2 = bytes 0-255, 1 = bytes 256-511) (repeat) As others have mentioned, it may be the chipset waiting until that 16-byte on-chip buffer fills up, as the acknowledgment packet is really small. And, the payload packet size can be really small if all bytes are the same - RLE encoding would pack an "empty" block into just a few bytes too. - David From ozgurovic at hotmail.com Wed Sep 16 05:09:37 2009 From: ozgurovic at hotmail.com (Ozgur Erkent) Date: Wed, 16 Sep 2009 14:09:37 +0300 Subject: [Rxtx] FTDI chipset speed - much slower? In-Reply-To: <4AB0B44F.9060201@attglobal.net> References: <4AB044A0.10509@attglobal.net> <4AB0B44F.9060201@attglobal.net> Message-ID: Has anybody tried to experiment the latency time of FTDI USB2Serial? (its latency wrt serial port) after preferably sending command from the computer, probably by keeping track of time after command is sent, its echo back time. In different languages would be good to compare them. ?zg?r Erkent > Date: Wed, 16 Sep 2009 05:47:59 -0400 > From: david at attglobal.net > To: rxtx at qbang.org > Subject: Re: [Rxtx] FTDI chipset speed - much slower? > > Trent Jarvi wrote: > > On Tue, 15 Sep 2009, David Schmidt wrote: > >> I'm suspecting I'm doing something wrong along the way that is > >> reacting badly with this chipset. My initial, lazy question, before > >> exposing my code to the harsh light of day: is there anything obvious > >> I might be doing wrong to this chipset to make it run so slowly? Has > >> anyone else run into the same problem? > > > > Given that rxtx does not treat usb special, it may be something to do > > with the nature of USB serial dongles. One suspicion I've had is that > > the event loop is competing for bandwidth by trying to check the UART > > status which is on the other side of the USB line. > > > > 1/5th is fairly significant. This is just writing/reading? How large > > are the transfers? > > The protocol is a little dance that happens with tiny packets, rapidly > sending/receiving (http://adtpro.sourceforge.net/protocol.html#Get). > > Host sends: > 2 bytes: current block number (LSB, MSB) > 1 byte: half-block number (2 = bytes 0-255, 1 = bytes 256-511) > up to 256 bytes: Half-block, RLE encoded > two bytes: > CRC (lo) > CRC (hi) > > Apple sends: > One byte: acknowledgement > Two bytes: current block number (LSB, MSB) > One byte: half-block number (2 = bytes 0-255, 1 = bytes 256-511) > > (repeat) > > As others have mentioned, it may be the chipset waiting until that > 16-byte on-chip buffer fills up, as the acknowledgment packet is really > small. And, the payload packet size can be really small if all bytes > are the same - RLE encoding would pack an "empty" block into just a few > bytes too. > > - David > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ More than messages?check out the rest of the Windows Live?. http://www.microsoft.com/windows/windowslive/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Wed Sep 16 05:15:23 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Wed, 16 Sep 2009 07:15:23 -0400 (EDT) Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby In-Reply-To: <0EB22ACB-0676-44DE-BBD3-A9D38CFD2E88@myller.com> Message-ID: <11479259.481253099719746.JavaMail.gjohnson@pippin.local> This is a big problem for us, and one we have resorted to the duct tape solution for as we can't find anything better :( The notion of an additional event coming up from the native code sounds very promising! Cheers, greg -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com ----- Original Message ----- From: "Ilkka Myller" To: "Trent Jarvi" , "Daniel Weinand" , "Stefan Frings, VF-DE" Cc: "rxtx at qbang.org" Sent: Wednesday, September 16, 2009 3:06:41 AM GMT -05:00 US/Canada Eastern Subject: Re: [Rxtx] Error 0x5 in termios.c after wake-up from standby Windows is not my primary platform, but I agree with Trent. I tested this too and noticed that ClearCommError() does not fail because RXTX loses fd (why would it), but because fd seems to no longer exist, or is reused, on kernel side. Resulting in access denied(5) error. Definitely something RXTX has no control of. Also the USB device re-registers itself, causing all it's previous file handles invalidated. After few seconds after waking from sleep, new ones can be created with CreateFile calls - as expected. FTDI chips can be reprogrammed not to do this reconnection cycle on USB sleep (with mprog 3.5 software). I dont know how well Windows follows that setting. Also Windows allows disabling USB power saving on specific USB devices. After those settings, it entirely up to the USB driver to do the right thing. .. which I'm not entirely sure it will - even if it's technically possible to retain fd's over sleep the driver might still be hardwired to reconnect the device on power save events. -- Basicly all these issues are about the fact that someone/something rips off the UART hardware RXTX is controlling. The serial comms features on most operating systems are not equipped to handle this since UART is expected to be integral part of the system. Well, USB has certainly changed that. Now not only the serial device can be unplugged (which is handled properly by protocols etc.) but the actual interface hardware too. Like ripping off the engine from your car while driving. For those reasons this issue is very hard for RXTX or any other serial comms library to handle. We could detect errors from kernel that indicate the UART has vanished and proceed to do automatic reopening of the serial port after some delay at the native lib. But: this has multiple issues, which probably will break user protocols and software. One of those is the fact that reopening the port could toggle its CTS/RTS/DTR/DSR signals causing unexpected trouble on user side. Other one is that we might end up in infinite loop of comm error <-> automatic reopening without notifying rxtx java side. Not elegant. Not proper. -- I'm proposing a following solution: We could implement a method to detect lost UART in event loop at native lib side and introduce a new Java side SerialPortEvent type UART_DISCONNECT. The native lib would send that event in case of error and proceed to automatically close the serial port and clear the invalid handles etc. (reset to fault free state). That would allow user code to gracefully handle these situations, by doing whatever is necessary to restore communications with their protocols etc. Usually that includes opening the serial port and doing some initializations. Those who choose to ignore that event, or not implement any handling for it, can continue to use RXTX as any other serial comms lib. But their software would still tumble and fall on UART disconnects - mostly caused by USB->UART bridges. Atleast, we'd have a method for implementing proper recovery if RXTX user chooses to do so. Beats duct tape+USB dongle combo anytime;) Feedback welcome :) -- I On Tue, 15 Sep 2009, Daniel Weinand wrote: Error 0x5 at ..\src\termios.c(2712): Access Denied Error 0x5 at ..\src\termios.c(517): Access Denied ... It is a known problem. The kernel driver isnt restoring the fd. See the previous post for what is required prior to being able to handle it in your code. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Wed Sep 16 05:42:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 16 Sep 2009 05:42:08 -0600 (MDT) Subject: [Rxtx] FTDI chipset speed - much slower? In-Reply-To: References: Message-ID: On Wed, 16 Sep 2009, Frings, Stefan, VF-DE wrote: > Hello David, > ? > Im not 100% sure, but I highly assume that the delays are produces by the > USB communication. USB transfers data in packets and there are large > buffers of several hundreds characters, similar to ethernet. There is no > real time communication. > ? > So when your software thinks that it has sent a character, this was not > the case. It was only put into a buffer and will appears at the end of > your USB2Serial cable after some time - I assume somewhat around 0,3ms. > ? > I noticed the same behavious with different USB2Serial adapters on Linux > with plain C programs (not anything around Java and RxTx). > ? I have seen some simple native C applications that do not inspect the LSR manage to send bytes closer to how an onboard UART does. In that case it was just two bytes being observed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Sep 16 05:55:14 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 16 Sep 2009 05:55:14 -0600 (MDT) Subject: [Rxtx] Error 0x5 in termios.c after wake-up from standby In-Reply-To: <0EB22ACB-0676-44DE-BBD3-A9D38CFD2E88@myller.com> References: <4AAF5838.7080707@gmail.com> <0EB22ACB-0676-44DE-BBD3-A9D38CFD2E88@myller.com> Message-ID: I think that will be fine. I'm not sure about all the corner cases with bluetooth dongles. On Wed, 16 Sep 2009, Ilkka Myller wrote: > Windows is not my primary platform, but I agree with Trent. > > I tested this too and noticed that ClearCommError() does not fail because > RXTX loses fd (why would it), but because fd seems to no longer exist, or > is reused, on kernel side. Resulting in access denied(5) error. > Definitely something RXTX has no control of. > Also the USB device re-registers itself, causing all it's previous file > handles invalidated. After few seconds after waking from sleep, new ones > can be created with CreateFile calls - as expected. > > FTDI chips can be reprogrammed not to do this reconnection cycle on USB > sleep (with mprog 3.5 software). I dont know how well Windows follows > that setting. Also Windows allows disabling USB power saving on specific > USB devices. > > After those settings, it entirely up to the USB driver to do the right > thing. .. which I'm not entirely sure it will - even if it's technically > possible to retain fd's over sleep the driver might still be hardwired to > reconnect the device on power save events. > > -- > > Basicly all these issues are about the fact that someone/something rips > off the UART hardware RXTX is controlling. The serial comms features on > most operating systems are not equipped to handle this since UART is > expected to be integral part of the system. Well, USB has certainly > changed that.? > Now not only the serial device can be unplugged (which is handled > properly by protocols etc.) but the actual interface hardware too. Like > ripping off the engine from your car while driving. > > For those reasons this issue is very hard for RXTX or any other serial > comms library to handle. We could detect errors from kernel that indicate > the UART has vanished and proceed to do automatic reopening of the serial > port after some delay at the native lib. But: this has multiple issues, > which probably will break user protocols and software. One of those is > the fact that reopening the port could toggle its CTS/RTS/DTR/DSR signals > causing unexpected trouble on user side. Other one is that we might end > up in infinite loop of comm error <-> automatic reopening without > notifying rxtx java side. Not elegant. Not proper. > > -- > > I'm proposing a following solution: > > We could implement a method to detect lost UART in event loop at native > lib side and introduce a new Java side SerialPortEvent type > UART_DISCONNECT.?The native lib would send that event in case of error > and proceed to automatically close the serial port and clear the invalid > handles etc. (reset to fault free state). > > That would allow user code to gracefully handle these situations, by > doing whatever is necessary to restore communications with their > protocols etc. Usually that includes opening the serial port and doing > some initializations. > > Those who choose to ignore that event, or not implement any handling for > it, can continue to use RXTX as any other serial comms lib. But their > software would still tumble and fall on UART disconnects - mostly caused > by USB->UART bridges. > > Atleast, we'd have a method for implementing proper recovery if RXTX user > chooses to do so. Beats duct tape+USB dongle combo anytime;) > > Feedback welcome :)? > > -- > I > > > > On Tue, 15 Sep 2009, Daniel Weinand wrote: > > Error 0x5 at ..\src\termios.c(2712): Access > Denied > > Error 0x5 at ..\src\termios.c(517): Access Denied > > ... > > > It is a known problem. ?The kernel driver isnt restoring the > fd. ?See the previous post for what is required prior to > being able to handle it in your code. > > > From tjarvi at qbang.org Wed Sep 16 18:10:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 16 Sep 2009 18:10:42 -0600 (MDT) Subject: [Rxtx] Fwd: [Patch] Implement new UART_DISCONNECT event (fwd) Message-ID: Attachments are pending. They got caught by the size restrictions. > L?hett?j?: Ilkka Myller > P?iv?ys: 17. syyskuuta 2009 0.14.50 UTC+3.00 > Vastaanottaja: "rxtx at qbang.org" > Aihe: [Patch] Implement new UART_DISCONNECT event > > > Summary: > > This patch adds support for new SerialPortEvent.UART_DISCONNECT event. > > Backwards compatibility: > > If RXTX user does not register event listener and request UART_DISCONNECT > events, the RXTX functions same as before. (=does not react to UART > disconnects - or behaviour is unspecified). > > Implementation: > > 1. The RXTX native lib eventLoop() checks for UART disconnection (for example > USB Adapter unplug/powersave) and sends UART_DISCONNECT event to interested > Java listeners. This happens as soon as serial ports file descriptor/handle > becomes invalid or points to no longer existing serial port driver io's. > Sometimes the UART drivers accept writes/reads few seconds after actual > disconnect (this is normal and depends on OS and the driver used). > > 2. The Java send_event() closes serial ports automatically and forwards the > UART_DISCONNECT event to user code/listener. > > 3. Subsequent calls to any RXTXPort IO function (except close() or > removeEventListener()) throws PortAlreadyClosedException which is subclass of > IOException --> no code changes necessary if IOExceptions are already handled > in user code. This is for backwards compatibility. > > 4. It's up to the user code to handle the proper recovery after receiving the > UART_DISCONNECT (usually involves trying to reopen the port and reinitialize > protocols) > > How UART disconnect is detected: > > eventLoop() uses conditionally defined CHECK_FD(int fd) function to check if > file descriptor points to valid (and existing) serial port. On windows this > means calling termios_check_fd() function and all others call > posix_check_fd() function. > > On linux/mac/other posix, CHECK_FD calls fstat, fcntl and ioctl (with > non-port-state-altering parameters) to check if file descriptor is valid and > device driver behind it responds properly. > > On windows, CHECK_FD calls GetCommState() to check if serial port handle is > still valid and port is accessible. > > If someone knows a better way (less overhead) to check if fd is valid, please > let me know:) Checking fd value >0 is not enough, since we have to detect if > UART driver actually responds even when we have fd > 0 too. > > Patch: > > The included patch is against CVS (@2009/09/16). > It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < > im-uart-disconnect1.patch' in rxtx-devel/src directory. > > The patch file does not include gnu/io/PortAlreadyClosedException.java, which > is included as separate attachment. > You must place this to rxtx-devel/src/gnu/io directory. > > Demonstration code: > > I've also included a simple demonstration code to test this feature. I've > tested it on Windows and on Mac OS X. > The SerialReconnectDemo(.java) writes few bytes to the serial port > continuously every 500ms. > If UART_DISCONNECT is received, it goes into reconnect() loop in separate > thread and tries to re-establish serial port connection. > If connection can be re-established, it continues operation normally. > It uses ReentrantLocks to properly synchronize serial port operations, which > is very useful with reconnect and writes --> if going to reconnect mode, > writes are blocked until connection is re-established. > > The demonstration code nicely survives from random disconnects of USB Serial > adapter. > > > Feedback: > > This is highly experimental implementation and details are likely to change. > Testing and any feedback is more than welcome. > Especially Trent, any thoughts? Am I missing something here? > > > > Thanks, > > -- > I > > > > > > > > From stefan.frings at vodafone.com Thu Sep 17 00:22:40 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Thu, 17 Sep 2009 08:22:40 +0200 Subject: [Rxtx] RXTX on Ubuntu 9.04 with lock in /var/lock/LCK..ttyS0 In-Reply-To: References: Message-ID: Hello petter, I installed the C library through using apt and I copied the jar file to the lib folder of my Java application. The I added myself to the dialout group. Nothing else. --- Good morning. Tanks for help me. I added the User and now with RXTX did not signal more trouble to lock the serial port, but my Java application can no longer capture the data (in my case shipped weight of an electronic scale). It is very strange, because Windows works normally, you know if Linux is needed any more setup RXTX to work well? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.frings at vodafone.com Thu Sep 17 00:25:56 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Thu, 17 Sep 2009 08:25:56 +0200 Subject: [Rxtx] FTDI chipset speed - much slower? Message-ID: Hello Ozgur, I can tell you a value from Silabs CP2102 chip. With a simple loopback connection on the serial end and a bitrate of 115200 (everything else left to the default settings), using Linux, the echo of 1-10 characters comes always back withing one milliseconds in a Java application using RxTxComm. I am not able to measure it more exactly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.frings at vodafone.com Thu Sep 17 00:31:35 2009 From: stefan.frings at vodafone.com (Frings, Stefan, VF-DE) Date: Thu, 17 Sep 2009 08:31:35 +0200 Subject: [Rxtx] RxTx handling disconnected USB devices Message-ID: Hello Ilkka, I highly appreciate your recommendation. The Java application should decide what to do when the device gets disconnected. When I disconnect /dev/ttyUSB0 and then reconnect it, I want to be able to re-open that port. Currently, this is not the case, because RxTxComm does not close it when I disconnect the device. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Thu Sep 17 00:44:24 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 17 Sep 2009 09:44:24 +0300 Subject: [Rxtx] [Patch] New feature: Implemented UART_DISCONNECT event Message-ID: <6E51B6F1-41C3-4FD5-B4A9-CBFD4AF83C85@myller.com> Summary: This patch implements new SerialPortEvent.UART_DISCONNECT event. Backwards compatibility: If RXTX user does not register event listener and request UART_DISCONNECT events, the RXTX functions same as before. (=does not react to UART disconnects - or behaviour is unspecified). Implementation: 1. The RXTX native lib eventLoop() checks for UART disconnection (for example USB Adapter unplug/powersave) and sends UART_DISCONNECT event to interested Java listeners. This happens as soon as serial ports file descriptor/handle becomes invalid or points to no longer existing serial port driver io's. Sometimes the UART drivers accept writes/ reads few seconds after actual disconnect (this is normal and depends on OS and the driver used). 2. The Java send_event() closes serial ports automatically and forwards the UART_DISCONNECT event to user code/listener. 3. Subsequent calls to any RXTXPort IO function (except close() or removeEventListener()) throws PortAlreadyClosedException which is subclass of IOException --> no code changes necessary if IOExceptions are already handled in user code. This is for backwards compatibility. 4. It's up to the user code to handle the proper recovery after receiving the UART_DISCONNECT (usually involves trying to reopen the port and reinitialize protocols) How UART disconnect is detected: eventLoop() uses conditionally defined CHECK_FD(int fd) function to check if file descriptor points to valid (and existing) serial port. On windows this means calling termios_check_fd() function and all others call posix_check_fd() function. On linux/mac/other posix, CHECK_FD calls fstat, fcntl and ioctl (with non-port-state-altering parameters) to check if file descriptor is valid and device driver behind it responds properly. On windows, CHECK_FD calls GetCommState() to check if serial port handle is still valid and port is accessible. If someone knows a better way (less overhead) to check if fd is valid, please let me know:) Checking fd value >0 is not enough, since we have to detect if UART driver actually responds even when we have fd > 0 too. Patch: The patch file is against CVS (@2009/09/16). It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < im- uart-disconnect1.patch' in rxtx-devel/src directory. The patch file does not include gnu/io/ PortAlreadyClosedException.java, which is included as separate file. You must place this to rxtx-devel/src/gnu/io directory. Due to mailing list restrictions, the attachments are inside .tar.gz archive. Demonstration code: I've also included a simple demonstration code to test this feature. I've tested it on Windows and on Mac OS X. The SerialReconnectDemo(.java) writes few bytes to the serial port continuously every 500ms. If UART_DISCONNECT is received, it goes into reconnect() loop in separate thread and tries to re-establish serial port connection. If connection can be re-established, it continues operation normally. It uses ReentrantLocks to properly synchronize serial port operations, which is very useful with reconnect and writes --> if going to reconnect mode, writes are blocked until connection is re-established. The demonstration code nicely survives from random disconnects of USB Serial adapter. Feedback: This is highly experimental implementation and details are likely to change. Testing and any feedback is more than welcome. Especially Trent, any thoughts? Am I missing something here? Thanks, -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im-uart-disconnect-1.tar.gz Type: application/x-gzip Size: 11834 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Wed Sep 16 22:49:25 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 17 Sep 2009 07:49:25 +0300 Subject: [Rxtx] [Patch] New feature: Implemented UART_DISCONNECT event Message-ID: <7E5DCEB5-650B-41F5-A2F3-861B96BAA00F@myller.com> Summary: This patch adds support for new SerialPortEvent.UART_DISCONNECT event. Backwards compatibility: If RXTX user does not register event listener and request UART_DISCONNECT events, the RXTX functions same as before. (=does not react to UART disconnects - or behaviour is unspecified). Implementation: 1. The RXTX native lib eventLoop() checks for UART disconnection (for example USB Adapter unplug/powersave) and sends UART_DISCONNECT event to interested Java listeners. This happens as soon as serial ports file descriptor/handle becomes invalid or points to no longer existing serial port driver io's. Sometimes the UART drivers accept writes/ reads few seconds after actual disconnect (this is normal and depends on OS and the driver used). 2. The Java send_event() closes serial ports automatically and forwards the UART_DISCONNECT event to user code/listener. 3. Subsequent calls to any RXTXPort IO function (except close() or removeEventListener()) throws PortAlreadyClosedException which is subclass of IOException --> no code changes necessary if IOExceptions are already handled in user code. This is for backwards compatibility. 4. It's up to the user code to handle the proper recovery after receiving the UART_DISCONNECT (usually involves trying to reopen the port and reinitialize protocols) How UART disconnect is detected: eventLoop() uses conditionally defined CHECK_FD(int fd) function to check if file descriptor points to valid (and existing) serial port. On windows this means calling termios_check_fd() function and all others call posix_check_fd() function. On linux/mac/other posix, CHECK_FD calls fstat, fcntl and ioctl (with non-port-state-altering parameters) to check if file descriptor is valid and device driver behind it responds properly. On windows, CHECK_FD calls GetCommState() to check if serial port handle is still valid and port is accessible. If someone knows a better way (less overhead) to check if fd is valid, please let me know:) Checking fd value >0 is not enough, since we have to detect if UART driver actually responds even when we have fd > 0 too. Patch: The included patch is against CVS (@2009/09/16). It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < im- uart-disconnect1.patch' in rxtx-devel/src directory. The patch file does not include gnu/io/ PortAlreadyClosedException.java, which is included as separate attachment. You must place this to rxtx-devel/src/gnu/io directory. Demonstration code: I've also included a simple demonstration code to test this feature. I've tested it on Windows and on Mac OS X. The SerialReconnectDemo(.java) writes few bytes to the serial port continuously every 500ms. If UART_DISCONNECT is received, it goes into reconnect() loop in separate thread and tries to re-establish serial port connection. If connection can be re-established, it continues operation normally. It uses ReentrantLocks to properly synchronize serial port operations, which is very useful with reconnect and writes --> if going to reconnect mode, writes are blocked until connection is re-established. The demonstration code nicely survives from random disconnects of USB Serial adapter. Feedback: This is highly experimental implementation and details are likely to change. Testing and any feedback is more than welcome. Especially Trent, any thoughts? Am I missing something here? Thanks, -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im-uart-disconnect-1.patch Type: application/octet-stream Size: 44545 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PortAlreadyClosedException.java Type: application/octet-stream Size: 3606 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialReconnectDemo.java Type: application/octet-stream Size: 5781 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Sep 17 21:20:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 17 Sep 2009 21:20:53 -0600 (MDT) Subject: [Rxtx] [Patch] New feature: Implemented UART_DISCONNECT event In-Reply-To: <7E5DCEB5-650B-41F5-A2F3-861B96BAA00F@myller.com> References: <7E5DCEB5-650B-41F5-A2F3-861B96BAA00F@myller.com> Message-ID: On Thu, 17 Sep 2009, Ilkka Myller wrote: > > Summary: > > This patch adds support for new SerialPortEvent.UART_DISCONNECT event. > > Backwards compatibility: > > If RXTX user does not register event listener and request UART_DISCONNECT > events, the RXTX functions same as before. (=does not react to UART > disconnects - or behaviour is unspecified). > We have a section of methods that are extensions to the API at the bottom of the file. These are commented clearly as extensions for javadoc. The register method should go there. > Implementation: > > 1. The RXTX native lib eventLoop() checks for UART disconnection (for > example USB Adapter unplug/powersave) and sends UART_DISCONNECT event to > interested Java listeners. This happens as soon as serial ports file > descriptor/handle becomes invalid or points to no longer existing serial > port driver io's. Sometimes the UART drivers accept writes/reads few > seconds after actual disconnect (this is normal and depends on OS and the > driver used). > > 2. The Java send_event() closes serial ports automatically and forwards > the UART_DISCONNECT event to user code/listener. > > 3. Subsequent calls to any RXTXPort IO function (except close() or > removeEventListener()) throws PortAlreadyClosedException which is subclass > of IOException --> no code changes necessary if IOExceptions are already > handled in user code. This is for backwards compatibility. > I suspect this is a bit of a problem as it forces people to handle IOExceptions they normally didnt. Hmm. We may want to look at that again. I personally am OK with it but I think people should look it over. > 4. It's up to the user code to handle the proper recovery after receiving > the UART_DISCONNECT (usually involves trying to reopen the port and > reinitialize protocols) > > How UART disconnect is detected: > > eventLoop() uses conditionally defined CHECK_FD(int fd) function to check > if file descriptor points to valid (and existing) serial port. On windows > this means calling termios_check_fd() function and all others call > posix_check_fd() function. > > On linux/mac/other posix, CHECK_FD calls fstat, fcntl and ioctl (with > non-port-state-altering parameters) to check if file descriptor is valid > and device driver behind it responds properly. > > On windows, CHECK_FD calls GetCommState() to check if serial port handle > is still valid and port is accessible. > > If someone knows a better way (less overhead) to check if fd is valid, > please let me know:) Checking fd value >0 is not enough, since we have to > detect if UART driver actually responds even when we have fd > 0 too. > Looks good overall. I worry that there may be paths to deadlock on w32 as various layers try to redundantly make sure a write or read happens. I also worry that the new method signatures with exceptions will require code changes in older applications even though they extend IOExceptions. The windows checks are fine vs implementing a POSIX version. -- Trent Jarvi tjarvi at qbang.org From ilkka at myller.com Thu Sep 17 23:29:10 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 18 Sep 2009 08:29:10 +0300 Subject: [Rxtx] [Patch] New feature: Implemented UART_DISCONNECT event In-Reply-To: References: <7E5DCEB5-650B-41F5-A2F3-861B96BAA00F@myller.com> Message-ID: > > > We have a section of methods that are extensions to the API at the > bottom of the file. These are commented clearly as extensions for > javadoc. The register method should go there. > I agree. I'll move the method there. >> >> 3. Subsequent calls to any RXTXPort IO function (except close() or >> removeEventListener()) throws PortAlreadyClosedException which is >> subclass of IOException --> no code changes necessary if >> IOExceptions are already handled in user code. This is for >> backwards compatibility. >> > > I suspect this is a bit of a problem as it forces people to handle > IOExceptions they normally didnt. Hmm. We may want to look at that > again. I personally am OK with it but I think people should look it > over. > I do not think this is a problem for methods that already did throw IOException, but for those API extension-methods that previously did not? right? I did not add PortAlreadyClosed exception to any stuff that we inherit from Comm API. I assumed we can change our own extensions relatively freely if necessary. I changed the notify....() methods to handle the closed-serial-port - situation by making them do nothing in that case. They only change something if isOpen() returns true. Therefore they dont have to throw PortAlreadyClosedExceptions. That's fine, because they also dont have to return any values since they are void. But those RXTX extension methods that I modified to throw the new exception, usually return some values. If we make them to behave like notify..(), they still have to return something - with closed serial port. What value would that be? Determining proper return value for those is bit difficult since they obviously cant call native methods with fd==0.. So basicly, that is why I chose to throw PortAlreadyClosed exception from them. The alternative did not feel any better. I hate to change the API ... even RXTX extensions ... but I think it's the right thing to do here if we want to implement this feature. As an example, the current implementation with added new exception.... public byte getParityErrorChar( ) throws UnsupportedCommOperationException, PortAlreadyClosedException { byte ret; checkPortAlreadyClosed(); ret = nativeGetParityErrorChar(); return( ret ); } ..versus non PortAlreadyClosed -exception alternative.. public byte getParityErrorChar( ) throws UnsupportedCommOperationException { if ( isOpen() == true ) { byte ret; ret = nativeGetParityErrorChar(); return( ret ); } else { return ( ); } } Thats the problem. We could however, throw UnsupportedCommOperationException and keep the method interface intact. But that would break the contract for the usage/meaning of UnsupportedCommOperationException ... and causes even more trouble for users. > > I worry that there may be paths to deadlock on w32 as various layers > try to redundantly make sure a write or read happens. We dont want that. Did you notice that I replaced fd verification in read/write with new termios_check_fd()'s.? Any ideas? > The windows checks are fine vs implementing a POSIX version. > I still feel that those checks are not optimal. There should be a cleaner way to verify that device driver responds behind fd.. instead of just requesting status registers from it. -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Fri Sep 18 05:27:43 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 18 Sep 2009 13:27:43 +0200 Subject: [Rxtx] Checking jni calls Message-ID: <7a803d460909180427h6a43b0c8i89734888aac2ffd4@mail.gmail.com> Hi I am trying to troubleshoot our code that talks to several devices on the serial port using RXTX, and I came across a tip from sun to run the java code with the -Xcheck:jni flag set. The code did not run very long before failing. Does anyone know what line of code in the eventLoop is causing this failure (I'm running this code on Windows XP 32bit)? I would like to patch this and create a new personal build of RXTX that runs even with the check:jni flag set. ... Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 18 Sep 2009 11:16:57,244 DEBUG serial.DeviceSerialConnection, line 90 - Opening COM-port on COM22 FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1575) -- Kjetil ?ster?s From tjarvi at qbang.org Sat Sep 19 13:47:17 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Sep 2009 11:47:17 -0600 (MDT) Subject: [Rxtx] [Patch] New feature: Implemented UART_DISCONNECT event In-Reply-To: References: <7E5DCEB5-650B-41F5-A2F3-861B96BAA00F@myller.com> Message-ID: On Fri, 18 Sep 2009, Ilkka Myller wrote: > > > We have a section of methods that are extensions to the API > at the bottom of the file. ?These are commented clearly as > extensions for javadoc. ?The register method should go there. > > > I agree. I'll move the method there. > > > 3. Subsequent calls to any RXTXPort IO function > (except close() or removeEventListener()) throws > PortAlreadyClosedException which is subclass of > IOException --> no code changes necessary if > IOExceptions are already handled in user code. > This is for backwards compatibility. > > > > I suspect this is a bit of a problem as it forces people to > handle IOExceptions they normally didnt. ?Hmm. ?We may want > to look at that again. ?I personally am OK with it but I > think people should look it over. > > > I do not think this is a problem for methods that already did throw > IOException, but for those API extension-methods that previously did not? > right? > I did not add PortAlreadyClosed exception to any stuff that we inherit > from Comm API. I assumed we can change our own extensions relatively > freely if necessary. > > I changed the notify....() methods to handle the closed-serial-port > -situation by making them do nothing in that case. They only change > something if isOpen() returns true. Therefore they dont have to throw > PortAlreadyClosedExceptions. That's fine, because they also dont have to > return any values since they are void. > > But those RXTX extension methods that I modified to throw the new > exception, usually return some values. If we make them to behave like > notify..(), they still have to return something - with closed serial > port. What value would that be? Determining proper return value for those > is bit difficult since they obviously cant call native methods with > fd==0.. So basicly, that is why I chose to throw PortAlreadyClosed > exception from?them. The alternative did not feel any better. > > I hate to change the API ... even RXTX extensions ... but I think it's > the right thing to do here if we want to implement this feature.? > I'm fine with changing the signatures of the extensions. The original authors will be familiar with rxtx and can react. I don't think 1% of the applications out there use the extensions. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 1 02:38:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 1 Sep 2009 02:38:40 -0600 (MDT) Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks Ilkka The problem should be resolved (confirmed from two locations). I'll be trying to hunt down a Snow Leopard box tomorrow evening as well. On Tue, 1 Sep 2009, Ilkka Myller wrote: > Hi, > > CVS server is reachable, but when trying anonymous login it replies: > > " > Fatal error, aborting. > anonymous: no such system user > " > > It seems that the anonymous cvs account is not yet properly configured on the > new system. > > -- > I > >> On Mon, 31 Aug 2009, Trent Jarvi wrote: >> >> The server has been beemed to another location for those experiencing >> routing problems. >> >> in bash: >> >> export CVSROOT=:pserver:anonymous at qbang.org:2401/var/cvs/cvsroot >> cvs login (no passwd) >> cvs co -r commapi-0-0-1 rxtx-devel >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ilkka at myller.com Tue Sep 1 03:05:59 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 12:05:59 +0300 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: Thanks, The new CVS server works well :) I can also confirm that latest CVS version builds properly with unmodified Snow Leopard (Mac OS X 10.6) system: Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 gcc version 4.2.1 (Apple Inc. build 5646) Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) --> Resulting JNI library (Universal Binary): i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = 9d15fc488b301da8bf65b2c9456a7bbb --> Resulting JAR: RXTXComm.jar / 60942 bytes MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 Atleast it builds.. and probably works too. I have not tested that yet. -- I Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > The problem should be resolved (confirmed from two locations). I'll > be trying to hunt down a Snow Leopard box tomorrow evening as well. From jimmy.lee at emotum.com Tue Sep 1 05:07:19 2009 From: jimmy.lee at emotum.com (Jimmy Lee [emotum]) Date: Tue, 1 Sep 2009 21:07:19 +1000 Subject: [Rxtx] new CVS server - was Is 2.2pre1 supposed to run ok on Snow Leopard? In-Reply-To: References: <3682EFB2-5764-407F-9CD6-34752D3DAD69@myller.com> Message-ID: <112685a90909010407i6054acb5tc2b12196797bfaf1@mail.gmail.com> Could we access to the binaries? Please :) 2009/9/1 Ilkka Myller > Thanks, > > The new CVS server works well :) > > I can also confirm that latest CVS version builds properly with unmodified > Snow Leopard (Mac OS X 10.6) system: > > Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_I386 i386 > gcc version 4.2.1 (Apple Inc. build 5646) > Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) > > > --> Resulting JNI library (Universal Binary): > > i386-apple-darwin10.0.0/librxtxSerial.jnilib / 185960 bytes > > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 > librxtxSerial.jnilib (for architecture ppc7400): Mach-O bundle ppc > > MD5 (i386-apple-darwin10.0.0/librxtxSerial.jnilib) = > 9d15fc488b301da8bf65b2c9456a7bbb > > > --> Resulting JAR: > > RXTXComm.jar / 60942 bytes > > MD5 (RXTXComm.jar) = c6fb87db85db2c64ad5a34195239ded7 > > > > Atleast it builds.. and probably works too. I have not tested that yet. > > -- > I > > Trent Jarvi kirjoitti 1.9.2009 kello 11.38: > > The problem should be resolved (confirmed from two locations). I'll be >> trying to hunt down a Snow Leopard box tomorrow evening as well. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.johnson at rbr-global.com Tue Sep 1 06:21:28 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Tue, 1 Sep 2009 08:21:28 -0400 (EDT) Subject: [Rxtx] Snow Leopard binaries Message-ID: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> +1 for binaries - pretty please with sugar on top... -- Greg Johnson, PhD Director of Engineering RBR Ltd. www.rbr-global.com From fredm at alum.mit.edu Tue Sep 1 06:24:17 2009 From: fredm at alum.mit.edu (Fred G. Martin) Date: Tue, 1 Sep 2009 08:24:17 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> Message-ID: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> You can find one here: http://iharder.sourceforge.net/current/java/ Also, you need to add yourself (any rxtx user) to the uucp group. Niutils don't exist, but dscl is a replacement. There is info for using it here: http://aplawrence.com/MacOSX/directory_services.html Fred On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Tue Sep 1 07:03:37 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Tue, 1 Sep 2009 18:33:37 +0530 Subject: [Rxtx] Help for RXTX on mac Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time I am able to read the device but on second time, it hangs on COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then it was showing the PortInUseException, I replaced the RXTX library to 2.2Pre1 so it is showing this problem. Is this is a problem with RXTX on Mac? Please help. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: From ilkka at myller.com Tue Sep 1 07:57:06 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 16:57:06 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:02:31 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:02:31 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> Message-ID: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 08:43:49 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 17:43:49 +0300 Subject: [Rxtx] Help for RXTX on mac In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E0F0A44@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE@myller.com> Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Arseneau at Sun.COM Tue Sep 1 08:51:32 2009 From: Eric.Arseneau at Sun.COM (Eric Arseneau) Date: Tue, 01 Sep 2009 07:51:32 -0700 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24@sun.com> Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilkka at myller.com Tue Sep 1 09:24:30 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 1 Sep 2009 18:24:30 +0300 Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D@myller.com> Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjetilos at gmail.com Thu Sep 3 02:50:16 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Thu, 3 Sep 2009 10:50:16 +0200 Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s From Kapil_Gupta at hcl.in Thu Sep 3 06:52:21 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:22:21 +0530 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From Kapil_Gupta at hcl.in Thu Sep 3 07:15:19 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Thu, 3 Sep 2009 18:45:19 +0530 Subject: [Rxtx] Rxtx Digest, Vol 25, Issue 3 In-Reply-To: References: Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C50BB@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi myller, I have attached the code with the mail. Please help me if I am doing something wrong in it. Thanks & Regards, Kapil Gupta -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of rxtx-request at qbang.org Sent: Thursday, September 03, 2009 4:15 PM To: rxtx at qbang.org Subject: Rxtx Digest, Vol 25, Issue 3 Send Rxtx mailing list submissions to rxtx at qbang.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qbang.org/mailman/listinfo/rxtx or, via email, send a message with subject or body 'help' to rxtx-request at qbang.org You can reach the person managing the list at rxtx-owner at qbang.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Rxtx digest..." Today's Topics: 1. Re: Snow Leopard binaries (Ilkka Myller) 2. Re: Snow Leopard binaries (Ilkka Myller) 3. Re: Help for RXTX on mac (Ilkka Myller) 4. Re: Snow Leopard binaries (Eric Arseneau) 5. Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters (Ilkka Myller) 6. RXTX multiple crashes (Kjetil ?ster?s) 7. RXTX 2.2Pre + MacMini+ Deadlock while second time port open (Kapil Gupta) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Sep 2009 16:57:06 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Just be clear: are those 2.1.7 binaries? Not 2.2? -- I Fred G. Martin kirjoitti 1.9.2009 kello 15.24: > > You can find one here: http://iharder.sourceforge.net/current/java/ > > Also, you need to add yourself (any rxtx user) to the uucp group. > Niutils don't exist, but dscl is a replacement. There is info for > using it here: http://aplawrence.com/MacOSX/directory_services.html > > Fred > > On Tue, Sep 1, 2009 at 8:21 AM, Greg Johnson > wrote: > +1 for binaries - pretty please with sugar on top... > > -- > Greg Johnson, PhD > Director of Engineering > RBR Ltd. > www.rbr-global.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 1 Sep 2009 17:02:31 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <55EC133D-DC83-45A3-849C-02714904D580 at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sorry, my rudeness was not intentional (a typo). Lets try again.. ;) "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" -- I > Just be clear: are those 2.1.7 binaries? Not 2.2? >> >> You can find one here: http://iharder.sourceforge.net/current/java/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 1 Sep 2009 17:43:49 +0300 From: Ilkka Myller To: rxtx Subject: Re: [Rxtx] Help for RXTX on mac Message-ID: <3CC4E3D8-196D-4858-ACBE-0B35E035F6CE at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi Kapil, I personally do not have any problems reopening serial ports with RXTX on Mac with latest CVS version, but I had those problems with earlier 2.2 builds. If I remember correctly there was a confirmed bug (and patch for it) related to this. If you are using USB<->Serial converter you could also try updating your drivers if necessary (most commonly FTDI or Prolific). If the problem persists maybe you could provide a simple port open- >close->reopen code. That would make it much easier to debug the issue. Thanks, -- I > I am using RXTX on Macintosh to communicate to my device. First time > I am able to read the device but on second time, it hangs on > COMPort.open (name, timeout); When I was using the RXTX 2.1.7, then > it was showing the PortInUseException, I replaced the RXTX library > to 2.2Pre1 so it is showing this problem. Is this is a problem with > RXTX on Mac? Please help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Tue, 01 Sep 2009 07:51:32 -0700 From: Eric Arseneau Cc: rxtx Subject: Re: [Rxtx] Snow Leopard binaries Message-ID: <63D8C98E-9676-45C1-9A1E-02B7F02C5C24 at sun.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Seems to be 2.1.7pre2 and seems to work for me. HUGE thank you for putting it up. On Sep 1, 2009, at 7:02 AM, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > -- > I > >> Just be clear: are those 2.1.7 binaries? Not 2.2? > >>> >>> You can find one here: http://iharder.sourceforge.net/current/java/ > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 1 Sep 2009 18:24:30 +0300 From: Ilkka Myller To: rxtx Subject: [Rxtx] Mac OS X 10.6 (Snow Leopard) / USB To Serial Adapters Message-ID: <914E18BE-A060-4925-9E84-AAD22377CC7D at myller.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi all, For those interested: Here's a list of latest USB to Serial Mac drivers I've tested to be Mac OS X 10.6 (Snow Leopard) compatible: -- FTDI FT-series based adapters: http://www.ftdichip.com/Drivers/VCP.htm Driver file: FTDIUSBSerialDriver_v2_2_14.dmg Latest driver is v2.2.14. For Prolific PL2303 (Generic): http://www.prolific.com.tw/eng/downloads.asp?ID=31 Driver file: md_pl2303H_HX_X_dmg_v1.2.1r2.zip Latest driver is v1.2.1r2 For ATEN UC-232AC (Prolific PL2303, but with different usb ids): http://www.aten.com/download/download.php?pid=2005022316346005&type=driver#showResult Driver file: uc232a_mac10.4.rar Latest driver is v1.3.0 (download link reports v1.0 - which is incorrect. Also: do not download v2.1 for OS X 10.4+). -- Please note that FTDI just released new drivers for Snow Leopard few days ago! I have tested all the listed drivers to work with Mac OS X 10.6 (Snow Leopard) Build 10A432 Here are kernel log messages for all drivers starting in 10.6: FTDIUSBSerialDriver: 0 4036001 start - ok PL-2303/X V1.2.1 start, Prolific PL-2303/X V1.3.0 start, UC-232AC -- I -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Thu, 3 Sep 2009 10:50:16 +0200 From: Kjetil ?ster?s To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Message-ID: <7a803d460909030150j7c04c096s569277711a7cae72 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s ------------------------------ Message: 7 Date: Thu, 3 Sep 2009 18:22:21 +0530 From: Kapil Gupta To: "rxtx at qbang.org" Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059 at NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset="us-ascii" Hi Team, I am using RXTX on Macintosh to communicate to my device. First time the device responds well but on second time, it hangs on COMPort.open (name, timeout). While debugging it seems that the port is not closed properly in first instance. I have attached the source code in a file. Please help me. Thanks & Best Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: ------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx End of Rxtx Digest, Vol 25, Issue 3 *********************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler2.java Type: application/octet-stream Size: 11242 bytes Desc: SerialDeviceHandler2.java URL: From ilkka at myller.com Thu Sep 3 11:17:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Thu, 3 Sep 2009 20:17:27 +0300 Subject: [Rxtx] RXTX 2.2Pre + MacMini+ Deadlock while second time port open In-Reply-To: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> References: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E1C5059@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Message-ID: <4520677F-E8F0-46F5-B4AD-3AD3A7C2AED3@myller.com> Hi Kapil, The code is incomplete and I did not find anything I could to test/ debug with this. I also tried to find the actual serial port opening, but found only a call to missing method which creates the SerialPort object (?): serialPort = getSerialPortConnection( COMPort, this.readEvent.getDeviceName(), SerialCommConfig.DEVICE1[SerialCommConfig.TIMEOUT], SerialCommConfig.DEVICE1[SerialCommConfig.BAUDRATE], SerialCommConfig.DEVICE1[SerialCommConfig.DATABITS], SerialCommConfig.DEVICE1[SerialCommConfig.STOPBITS], SerialCommConfig.DEVICE1[SerialCommConfig.PARITY] ); The class SerialCommConfig is missing too. If this is a part of the actual code you are using, please note that you are not actually closing the serial port. The call to close() method is commented out: try { // serialPort.close(); } catch (Exception ex) { ex.printStackTrace(); } Re-opening of the serial port wont work if you haven't properly closed it first. -- I > > I am using RXTX on Macintosh to communicate to my device. First time > the device responds well but on second time, it hangs on > COMPort.open (name, timeout). > > I have attached the source code in a file. Please help me. > > Thanks & Best Regards, > Kapil -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorton at intellimec.com Thu Sep 3 11:37:55 2009 From: dmorton at intellimec.com (Daniel Morton) Date: Thu, 3 Sep 2009 13:37:55 -0400 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. (I haven't tried previous version though). Daniel Morton Java/J2EE Developer Tel +1 519.745.8887 x4331 Email dmorton at intellimec.com www.intellimec.com | www.iLane.com | www.drivesync.com Intelligent Mechatronic Systems Inc. 435 King Street North Waterloo, ON N2J 2Z5 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s Sent: Thursday, September 03, 2009 4:50 AM To: rxtx at qbang.org Subject: [Rxtx] RXTX multiple crashes Hi We are using RXTX version 2.1.7 actively and lately we are having some issues with the RXTX library crashing. We are running a windows xp system with multiple COM ports where each COM port have a serial device connected. Lately we have increased the amount of signaling done over the COM ports and we are experiencing several odd crashes. I tried to search the mailinglist for something similar but was unable to find anything. At one time the RXTX crashed in the gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack traces if someone is interested in having a look. Has anyone seen the same crashes? and does anyone know what can cause such crash? # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x7d0d] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ce75800): JavaThread "Y Worker" daemon [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 Registers: EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 EIP=0x10007d0d, EFLAGS=0x00010202 Top of Stack: (sp=0x0d7ff6d8) 0x0d7ff6d8: 0d7ff700 00000000 00000000 00000000 0x0d7ff6e8: 02a2eae8 00000123 00002958 0d7ff718 0x0d7ff6f8: 7c830887 7c90d28a 7c8664b5 00000e2c 0x0d7ff708: 00002958 00000000 00000000 7c90cffa 0x0d7ff718: 7c809bdb 00002958 0d7ff758 00000e40 0x0d7ff728: 00002958 02bd0468 0ce75800 080e4ee0 0x0d7ff738: 00000000 00000000 00000000 00000000 0x0d7ff748: 00000000 00000000 00000014 7c90d09a Instructions: (pc=0x10007d0d) 0x10007cfd: 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 0x10007d0d: 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x7d0d] J gnu.io.RXTXPort.nativeDrain(Z)Z J gnu.io.RXTXPort$SerialOutputStream.flush()V ... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 # # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # Problematic frame: # C [rxtxSerial.dll+0x9c55] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0cddf400): JavaThread "XXX Worker" daemon [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 Registers: EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 EIP=0x10009c55, EFLAGS=0x00010206 Top of Stack: (sp=0x0bb8f830) 0x0bb8f830: 00000000 00000000 c0000005 00000000 0x0bb8f840: 00000000 00f1f0a5 00000002 00000000 0x0bb8f850: 003a0100 0001003f 0bb8fb20 0b9ff918 0x0bb8f860: 00000000 00000000 0bb8fb68 0bb8fb20 0x0bb8f870: 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 0x0bb8f880: 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 0x0bb8f890: 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 0x0bb8f8a0: 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 Instructions: (pc=0x10009c55) 0x10009c45: 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff 0x10009c55: 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x9c55] C [rxtxSerial.dll+0xa05e] J gnu.io.RXTXPort.readByte()I J gnu.io.RXTXPort$SerialInputStream.read()I J java.io.FilterInputStream.read()I ... -- Kjetil ?ster?s _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. From alexanderkiel at gmx.net Fri Sep 4 02:29:15 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 10:29:15 +0200 Subject: [Rxtx] Official Javadoc Location Message-ID: <1252052955.4025.80.camel@T61-KIEL> Hi List, I wasn't able to find an official location of RXTX Javadoc accessible over HTTP. Maybe someone can link me to it. If there is no such location, I would like to see one. I like to link from my own Javadoc to such a location. Thanks Alexander - e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:19:25 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:19:25 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <302aa0340909040148p3a2bd2e3j74e8505088e49e28@mail.gmail.com> Message-ID: <1252055965.4025.84.camel@T61-KIEL> Hi Michael, thanks for the pointer. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 09:48 +0100, Michael Tandy wrote: > RxTx javadoc: http://users.frii.com/jarvi/rxtx/doc/index.html > Javax interface RxTx duplicates javadoc: > http://java.sun.com/products/javacomm/reference/api/index.html > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexanderkiel at gmx.net Fri Sep 4 03:22:14 2009 From: alexanderkiel at gmx.net (Alexander Kiel) Date: Fri, 04 Sep 2009 11:22:14 +0200 Subject: [Rxtx] Official Javadoc Location In-Reply-To: <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> References: <1252052955.4025.80.camel@T61-KIEL> <87f2add00909040204v513f2ac5y6b1d063924a9da5c@mail.gmail.com> Message-ID: <1252056134.4025.87.camel@T61-KIEL> Hi Eike, thanks, but I need a direct package pointer so that Javadoc will link the gnu.io packages automatically to the right location. Michael has pointed me to http://users.frii.com/jarvi/rxtx/doc/index.html which has the gnu.io packages. Regards Alexander -- e-mail: alexanderkiel at gmx.net web: www.alexanderkiel.net On Fri, 2009-09-04 at 11:04 +0200, Eike Hinderk J?rrens wrote: > Hi Alexander, > it seems to me that RXTX is implementing this API: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Kind regards, > Eike > > 2009/9/4 Alexander Kiel : > > Hi List, > > > > I wasn't able to find an official location of RXTX Javadoc accessible > > over HTTP. Maybe someone can link me to it. > > > > If there is no such location, I would like to see one. I like to link > > from my own Javadoc to such a location. > > > > Thanks > > Alexander > > > > - > > e-mail: alexanderkiel at gmx.net > > web: www.alexanderkiel.net > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kjetilos at gmail.com Fri Sep 4 03:43:41 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 11:43:41 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> <0B7E041EB0F9A64ABF22DD3E8120939A050A4088@imsmail.imscorp.intellimec.com> Message-ID: <7a803d460909040243ke4449ecucbe2cd8b15761746@mail.gmail.com> Hi Daniel, This is interesting, what type of application are you making? Is there a lot of signaling on different COM ports at the same time in your application? In our application we have 11 devices connected to different COM ports, 9 of these are in active use when the application is running. I'm wondering how to use the RXTX library version 2.1.7 in this scenario without causing it to crash. After adding more signaling on the COM ports in our application we have now experienced other crashes and it is natural to think that it has something to do with our way of using RXTX from several threads at the same time. So my question is are there any methods like read/write/flush/close that are not thread safe and should be handled with care? And similarly is the RXTXPort.SerialInputStream and RXTXPort.SerialOutputStream thread safe? 2009/9/3 Daniel Morton : > I can't offer any help with this, but I thought I'd mention that I've been having the exact same problem happen quite regularly with 2.1.7. ?(I haven't tried previous version though). > > Daniel Morton > Java/J2EE Developer > > Tel ? ?+1 519.745.8887 x4331 > Email ? ?dmorton at intellimec.com > > > www.intellimec.com ?| ?www.iLane.com ?| ?www.drivesync.com > > > > Intelligent Mechatronic Systems Inc. > 435 King Street North Waterloo, ON N2J 2Z5 > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kjetil ?ster?s > Sent: Thursday, September 03, 2009 4:50 AM > To: rxtx at qbang.org > Subject: [Rxtx] RXTX multiple crashes > > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10007d0d, pid=3592, tid=3292 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x7d0d] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0ce75800): ?JavaThread "Y Worker" daemon > [_thread_in_native, id=3292, stack(0x0d7b0000,0x0d800000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0bc2f9a4 > > Registers: > EAX=0x0bc2f998, EBX=0x00000000, ECX=0x0d7ff97c, EDX=0x0d7ff6a0 > ESP=0x0d7ff6d8, EBP=0x0d7ffa00, ESI=0x02bd0468, EDI=0x0ce75800 > EIP=0x10007d0d, EFLAGS=0x00010202 > > Top of Stack: (sp=0x0d7ff6d8) > 0x0d7ff6d8: ? 0d7ff700 00000000 00000000 00000000 > 0x0d7ff6e8: ? 02a2eae8 00000123 00002958 0d7ff718 > 0x0d7ff6f8: ? 7c830887 7c90d28a 7c8664b5 00000e2c > 0x0d7ff708: ? 00002958 00000000 00000000 7c90cffa > 0x0d7ff718: ? 7c809bdb 00002958 0d7ff758 00000e40 > 0x0d7ff728: ? 00002958 02bd0468 0ce75800 080e4ee0 > 0x0d7ff738: ? 00000000 00000000 00000000 00000000 > 0x0d7ff748: ? 00000000 00000000 00000014 7c90d09a > > Instructions: (pc=0x10007d0d) > 0x10007cfd: ? 74 05 31 c0 eb 45 90 83 7d f4 00 74 3a 8b 45 f4 > 0x10007d0d: ? 83 78 0c 00 74 31 8d 85 e0 fc ff ff 8b 55 f4 52 > > > Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x7d0d] > J ?gnu.io.RXTXPort.nativeDrain(Z)Z > J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > ... > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10009c55, pid=1912, tid=3284 > # > # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) > # Problematic frame: > # C ?[rxtxSerial.dll+0x9c55] > # > # If you would like to submit a bug report, please visit: > # ? http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- ?T H R E A D ?--------------- > > Current thread (0x0cddf400): ?JavaThread "XXX Worker" daemon > [_thread_in_native, id=3284, stack(0x0bb40000,0x0bb90000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0b9ff920 > > Registers: > EAX=0x0b9ff918, EBX=0x00000000, ECX=0x00000001, EDX=0x0b9ff918 > ESP=0x0bb8f830, EBP=0x0bb8fa18, ESI=0x03aed4a8, EDI=0x0cddf400 > EIP=0x10009c55, EFLAGS=0x00010206 > > Top of Stack: (sp=0x0bb8f830) > 0x0bb8f830: ? 00000000 00000000 c0000005 00000000 > 0x0bb8f840: ? 00000000 00f1f0a5 00000002 00000000 > 0x0bb8f850: ? 003a0100 0001003f 0bb8fb20 0b9ff918 > 0x0bb8f860: ? 00000000 00000000 0bb8fb68 0bb8fb20 > 0x0bb8f870: ? 0bb8fb14 00290188 0bb8fb0c 0bb8fb08 > 0x0bb8f880: ? 073a001b 0bb8fb18 0bb8fafc 0bb8faf8 > 0x0bb8f890: ? 0bb8fa74 0bb8fa78 0b860000 0bb8fa80 > 0x0bb8f8a0: ? 0bb8fa84 0bb8fa88 0bb8fa8c 0bb8fa90 > > Instructions: (pc=0x10009c55) > 0x10009c45: ? 00 83 c4 10 89 85 44 fe ff ff 8b 85 44 fe ff ff > 0x10009c55: ? 8b 50 08 89 95 4c fe ff ff 8b 85 44 fe ff ff c7 > > > Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C ?[rxtxSerial.dll+0x9c55] > C ?[rxtxSerial.dll+0xa05e] > J ?gnu.io.RXTXPort.readByte()I > J ?gnu.io.RXTXPort$SerialInputStream.read()I > J ?java.io.FilterInputStream.read()I > ... > > -- > Kjetil ?ster?s > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > This e-mail message is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform us immediately and delete this e-mail message and destroy all copies. Thank you. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kjetil ?ster?s From tjarvi at qbang.org Fri Sep 4 06:00:40 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Sep 2009 06:00:40 -0600 (MDT) Subject: [Rxtx] RXTX multiple crashes In-Reply-To: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > Hi > > We are using RXTX version 2.1.7 actively and lately we are having some > issues with the RXTX library crashing. We are running a windows xp > system with multiple COM ports where each COM port have a serial > device connected. Lately we have increased the amount of signaling > done over the COM ports and we are experiencing several odd crashes. I > tried to search the mailinglist for something similar but was unable > to find anything. At one time the RXTX crashed in the > gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the > gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack > traces if someone is interested in having a look. Has anyone seen the > same crashes? and does anyone know what can cause such crash? > > > Stack: [0x0d7b0000,0x0d800000], sp=0x0d7ff6d8, free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x7d0d] > J gnu.io.RXTXPort.nativeDrain(Z)Z > J gnu.io.RXTXPort$SerialOutputStream.flush()V > Stack: [0x0bb40000,0x0bb90000], sp=0x0bb8f830, free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [rxtxSerial.dll+0x9c55] > C [rxtxSerial.dll+0xa05e] > J gnu.io.RXTXPort.readByte()I > J gnu.io.RXTXPort$SerialInputStream.read()I RXTX 2.1-7 has concurrency issues that will show upon multicore systems. These should be resolved in the 2.2 pre release. A user application could synchronize the read/write/open/close calls while using 2.1 to avoid the concurrency issue. The flush is probably following a write while the readByte is coming from read(byte b). The bugs existed in rxtx for a long time. I assume changes in the JVM and the presence of multicore systems exposed the issues. -- Trent Jarvi tjarvi at qbang.org From kjetilos at gmail.com Fri Sep 4 06:33:33 2009 From: kjetilos at gmail.com (=?ISO-8859-1?Q?Kjetil_=D8ster=E5s?=) Date: Fri, 4 Sep 2009 14:33:33 +0200 Subject: [Rxtx] RXTX multiple crashes In-Reply-To: References: <7a803d460909030150j7c04c096s569277711a7cae72@mail.gmail.com> Message-ID: <7a803d460909040533n1caf240y8168477a578bc45c@mail.gmail.com> Den 4. september 2009 14.00 skrev Trent Jarvi f?lgende: > > > On Thu, 3 Sep 2009, Kjetil ?ster?s wrote: > >> Hi >> >> We are using RXTX version 2.1.7 actively and lately we are having some >> issues with the RXTX library crashing. We are running a windows xp >> system with multiple COM ports where each COM port have a serial >> device connected. Lately we have increased the amount of signaling >> done over the COM ports and we are experiencing several odd crashes. I >> tried to search the mailinglist for something similar but was unable >> to find anything. At one time the RXTX crashed in the >> gnu.io.RXTXPort.nativeDrain method, another time RXTX crashed in the >> gnu.io.RXTXPort.readByte method. I have pasted in parts of the strack >> traces if someone is interested in having a look. Has anyone seen the >> same crashes? and does anyone know what can cause such crash? >> >> >> Stack: [0x0d7b0000,0x0d800000], ?sp=0x0d7ff6d8, ?free space=317k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x7d0d] >> J ?gnu.io.RXTXPort.nativeDrain(Z)Z >> J ?gnu.io.RXTXPort$SerialOutputStream.flush()V > >> Stack: [0x0bb40000,0x0bb90000], ?sp=0x0bb8f830, ?free space=318k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> C ?[rxtxSerial.dll+0x9c55] >> C ?[rxtxSerial.dll+0xa05e] >> J ?gnu.io.RXTXPort.readByte()I >> J ?gnu.io.RXTXPort$SerialInputStream.read()I > > > RXTX 2.1-7 has concurrency issues that will show upon multicore systems. > These should be resolved in the 2.2 pre release. ?A user application could > synchronize the read/write/open/close calls while using 2.1 to avoid the > concurrency issue. > > The flush is probably following a write while the readByte is coming from > read(byte b). > > The bugs existed in rxtx for a long time. ?I assume changes in the JVM and > the presence of multicore systems exposed the issues. > Ok, so we should look more into using a newer version of RXTX. The current version from the webpage is 2.2pre2, what is the stability status of this version. Is it good enough for use in a production environment? -- Kjetil ?ster?s From martinezrodolfo at gmail.com Fri Sep 4 13:39:57 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Fri, 4 Sep 2009 15:09:57 -0430 Subject: [Rxtx] Problem with data available event Message-ID: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Hello list members. I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a serial port USB adapter to communicate with an electronical inmunoassay analyzer. The program works porperly with one model of the analyzer series. It defines a protocol which every message sent should be replied with an ACK in order to continue with the communication. Now we are trying to communicate with another model of the same brand and series wich in theory should be much of the same of what was previously done. Unfortunately, that is not the case. The problem with this connection is that it never fires the Data Available serial port event. Is like if nothing was being received in the input stream. The following code always prints zero when the equipment should be transmitting. ----------------------- beginning of sample code ---------------------------------- SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", 10000); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); int len = 0; byte[] readBuffer = new byte[8]; while (true) { len = in.read(readBuffer); System.out.println(len); writer.writeACK(); // writing ACK to analyzer } ----------------------- end of sample code ------------------------------------------ We know that the analyzer is transmitting because HyperTerminal does shows the proper output. In fact, after running the above code and connecting via Hyperterminal all data is received in one block. Is like the data sent from the analyzer is being held somewhere in the way. Sniffing at the serial port, noticed that IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this helps to find what might be wrong or not, but here they are: On Hyperterminal: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 XonLimit:80 XoffLimit:200 On Java: IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 XonLimit:0 XoffLimit:0 Thanks in advance for your help. Rodolfo M From ilkka at myller.com Sat Sep 5 04:36:27 2009 From: ilkka at myller.com (Ilkka Myller) Date: Sat, 5 Sep 2009 13:36:27 +0300 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <121198EE-65A4-463B-ACC7-29FFB9855B2C@myller.com> Hi Rodolfo, By default RXTX does not enable any flow control for the serial port. Please check what flow control you have active in HyperTerminal when you are able to receive data and then use the same flow control with RXTX serial port: serialPort.setFlowControlMode(int flowcontrol); Possible flowcontrol flags are (from SerialPort class) FLOWCONTROL_NONE FLOWCONTROL_RTSCTS_IN FLOWCONTROL_RTSCTS_OUT FLOWCONTROL_XONXOFF_IN FLOWCONTROL_XONXOFF_OUT For example, you can try enabling RTS/CTS hardware flow control. Note the bitwise OR operator ' | ': serialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT ); Also if your device requires RTS/CTS flow control make sure you have fully connected serial cable (not just RX, TX, GND for example, but also RTS, CTS, DTR). One thing you might want to check is the state of DTR (Data Terminal Ready). Some devices wait for the DTR signal before they send any data. You can enable or disable DTR signal (high/low) with: serialPort.setDTR( boolean state ); -- I > Hello list members. > > I've been using RXTX v2.1-7 with WindowsXP and Java 1.6 through a > serial port USB adapter to communicate with an electronical > inmunoassay analyzer. The program works porperly with one model of the > analyzer series. It defines a protocol which every message sent should > be replied with an ACK in order to continue with the communication. > Now we are trying to communicate with another model of the same brand > and series wich in theory should be much of the same of what was > previously done. Unfortunately, that is not the case. The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. > > ----------------------- beginning of sample code > ---------------------------------- > SerialPort serialPort = (SerialPort) portIden.open("AIAConnection", > 10000); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > InputStream in = serialPort.getInputStream(); > OutputStream out = serialPort.getOutputStream(); > > int len = 0; > byte[] readBuffer = new byte[8]; > while (true) { > len = in.read(readBuffer); > System.out.println(len); > > writer.writeACK(); // writing ACK to analyzer > } > ----------------------- end of sample code > ------------------------------------------ > > We know that the analyzer is transmitting because HyperTerminal does > shows the proper output. In fact, after running the above code and > connecting via Hyperterminal all data is received in one block. Is > like the data sent from the analyzer is being held somewhere in the > way. Sniffing at the serial port, noticed that > IOCTL_SERIAL_SETHANDFLOW values are different. I'm not sure if this > helps to find what might be wrong or not, but here they are: > > On Hyperterminal: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000009 Replace:80000080 > XonLimit:80 XoffLimit:200 > > On Java: > IOCTL_SERIAL_SET_HANDFLOW Serial2 Shake:80000001 Replace:0 > XonLimit:0 XoffLimit:0 > > > Thanks in advance for your help. > Rodolfo M > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.weber99 at gmx.net Sun Sep 6 13:51:12 2009 From: karl.weber99 at gmx.net (Karl Weber) Date: Sun, 6 Sep 2009 21:51:12 +0200 Subject: [Rxtx] Cannot create lock file Message-ID: <200909062151.12228.karl.weber99@gmx.net> Hi, I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an opensuse repository as well as from the homepage of the rxtx project. I have already added the user to the group uucp, however, it does not have any effect. What else do I have to do to make it work? (It does work with user root, though.) The error message is: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL Thanks in advance, Karl From tjarvi at qbang.org Sun Sep 6 13:51:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 6 Sep 2009 13:51:42 -0600 (MDT) Subject: [Rxtx] Cannot create lock file In-Reply-To: <200909062151.12228.karl.weber99@gmx.net> References: <200909062151.12228.karl.weber99@gmx.net> Message-ID: On Sun, 6 Sep 2009, Karl Weber wrote: > Hi, > > I have openSUSE 11.1 on an x86_64 architecture and tried the rxtx-java from an > opensuse repository as well as from the homepage of the rxtx project. > > I have already added the user to the group uucp, however, it does not have > any effect. What else do I have to do to make it work? (It does work with > user root, though.) > > The error message is: > > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to > create lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > > Thanks in advance, Karl Look at the group that owns /var/lock with ls -ld /var/lock The following should work as a user when they are in the correct group: touch /var/lock/test && rm -f /var/lock/test -- Trent Jarvi tjarvi at qbang.org From Luca.Catoni at sysdat.it Mon Sep 7 06:32:42 2009 From: Luca.Catoni at sysdat.it (Luca Catoni) Date: Mon, 7 Sep 2009 14:32:42 +0200 Subject: [Rxtx] time-out implementation Message-ID: I need to implement a simple timer class to manage time-out in my RS-232 serial communication with a remote device using the rxtx library. The functions that the timer should have are start(), and reset() and start() method must throw an exception (TimeoutException) when it expires. I am not an expert in concurrent programming and I do not have much knowledge on threads. myTimer.setExpirationTime(myvalue); ? public void serialEvent(SerialPortEvent event) { if (event.getEventType() == SerialPortEvent.OUTPUT_BUFFER_EMPTY) { // transmission ? out.write(?); try{ myTimer.start(); }catch(TimeoutException te){ myTimer.reset(); ? } ? if (event.getEventType() == SerialPortEvent.DATA_AVAILABLE) { // receiving in.read(?); if (mycondition){ myTimer.stop();//ok, timer NOT expired myTimer.reset();//now I can call start() method again in //transmission to restart my timer when I //have to transmit next data } Can anyone help me to implement the class MyTimer? thanks in advance. -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kapil_Gupta at hcl.in Mon Sep 7 06:49:24 2009 From: Kapil_Gupta at hcl.in (Kapil Gupta) Date: Mon, 7 Sep 2009 18:19:24 +0530 Subject: [Rxtx] 2.2Pre + MacMini+ Deadlock while second time port Message-ID: <91958FAFDBC0ED4F8600DF946EA3CE3F4B2E22FB6F@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi, Please find the updated code (close call was commented by mistake). This code reproduces the problem on Macintosh but works fine on windows. This test works as follows: A command let say "abc" is sent to the device on port /dev/tty.usbtoserial and device responds to this command. Warm Regards, Kapil DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialDeviceHandler.java Type: application/octet-stream Size: 10405 bytes Desc: SerialDeviceHandler.java URL: From michael.erskine at ketech.com Mon Sep 7 09:13:03 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 7 Sep 2009 16:13:03 +0100 Subject: [Rxtx] Problem with data available event In-Reply-To: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Rodolfo Mart?nez > Subject: [Rxtx] Problem with data available event > The problem with > this connection is that it never fires the Data Available serial port > event. Is like if nothing was being received in the input stream. The > following code always prints zero when the equipment should be > transmitting. Hi Rodolfo, The sample code you provided doesn't implement or register any event listeners. Regards, Michael Erskine. From martinezrodolfo at gmail.com Mon Sep 7 10:21:22 2009 From: martinezrodolfo at gmail.com (=?ISO-8859-1?Q?Rodolfo_Mart=EDnez?=) Date: Mon, 7 Sep 2009 11:51:22 -0430 Subject: [Rxtx] Problem with data available event In-Reply-To: <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> References: <30eacee0909041239g76ab9c35g17c7300a81cd0020@mail.gmail.com> <06BA3262D918014F9183B66425D5A8D465EF8314D6@no-sv-03.ketech.local> Message-ID: <30eacee0909070921l7f285765ue2c661963183fd2b@mail.gmail.com> On Mon, Sep 7, 2009 at 10:43 AM, Michael Erskine wrote: > Hi Rodolfo, > The sample code you provided doesn't implement or register any event listeners. > > Regards, > Michael Erskine. Hi Michael, I didn't write the event listeners declaration on the sample code for simplicity, but I do implement them on my real code. I should have mentioned it on the sample code anyway... my bad. I haven't had access to the device I'm trying to connect, but tomorrow will. And hope that with the explanation of Ilkka Myller will succeed this time. Thanks for your attention. Rodolfo M From ajmas at sympatico.ca Mon Sep 7 16:58:13 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 7 Sep 2009 18:58:13 -0400 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: <55EC133D-DC83-45A3-849C-02714904D580@myller.com> References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > Sorry, my rudeness was not intentional (a typo). > Lets try again.. ;) > > "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" I noticed in the page you posted posted you indicated that you patched two files. Did you submit the changes to Jarvi, so they could be included in the main code branch? Andr? From tjarvi at qbang.org Mon Sep 7 16:57:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Sep 2009 16:57:53 -0600 (MDT) Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: On Mon, 7 Sep 2009, Andre-John Mas wrote: > > On 1-Sep-2009, at 10:02, Ilkka Myller wrote: > >> Sorry, my rudeness was not intentional (a typo). >> Lets try again.. ;) >> >> "Just to be clear about this: Are those 2.1.7 binaries? Not 2.2?" > > I noticed in the page you posted posted you indicated that you patched two > files. Did you submit the changes to Jarvi, so they could be included in the > main code branch? > Hi Andr? Ilkka is working with us to get changes in. I'm not sure about those two patches which may already be in CVS. I'll let him answer that. I've given him write access to CVS and asked him to cc the list non whitespace changes when they are ready. Right now he is asking questions off the list regarding cleaning up the Mac and w32 build files. -- Trent Jarvi tjarvi at qbang.org From nsp25 at cornell.edu Mon Sep 7 21:17:45 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Mon, 7 Sep 2009 23:17:45 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: (Sorry if this is a double post, but I sent my original message without subscribing, and since this is an urgent problem, I thought I'd resend after subscribing to bypass the moderator limbo zone) Hi all, I've asked my question on StackOverflow already, so rather than copy-paste the question here, I'd like to redirect you there . Short version, I am no longer able to receive anything over RS-232 with RXTX, but other programs work fine. I'm definitely sending things, because when I connect with a different program, all the responses to the commands I sent via RXTX arrive all at once. Everything was fine in the spring, so what could have happened? Windows update? -Nate -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.j.tandy at warwick.ac.uk Tue Sep 8 01:30:48 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Tue, 8 Sep 2009 08:30:48 +0100 Subject: [Rxtx] Problems with RX In-Reply-To: References: Message-ID: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> OK, so: 1. It worked in spring but has stopped doing so and 2. The data all arrives at once when you start hyperterminal. Is it possible you're using a different serial cable to connect to the device, compared to the one you were using in spring? If so, the issue might be hardware flow control - that is, your device might be buffering data because it can't transmit it until your computer sets 'DTR' or 'RTS' or something like that. One way of bypassing hardware flow control is by using cables which cross over certain wires so that the right signals are always being sent; it's possible your old cable had these connections but your current cable doesn't have them. If you can find the old cable, you could put it back in and see if that fixes things? 2009/9/8 Nathaniel S. Parsons : > (Sorry if this is a double post, but I sent my original message without > subscribing, and since this is an urgent problem, I thought I'd resend after > subscribing to bypass the moderator limbo zone) > > Hi all, > > I've asked my question on StackOverflow already, so rather than copy-paste > the question here, I'd like to redirect you there. > > Short version, I am no longer able to receive anything over RS-232 with > RXTX, but other programs work fine. I'm definitely sending things, because > when I connect with a different program, all the responses to the commands I > sent via RXTX arrive all at once. > > Everything was fine in the spring, so what could have happened? Windows > update? > > -Nate > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ilkka at myller.com Tue Sep 8 01:50:33 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 8 Sep 2009 10:50:33 +0300 Subject: [Rxtx] Snow Leopard binaries In-Reply-To: References: <9451695.14461251807686540.JavaMail.gjohnson@pippin.local> <72ef860f0909010524ue687addye3d0d555db4fe265@mail.gmail.com> <55EC133D-DC83-45A3-849C-02714904D580@myller.com> Message-ID: <111FEC9A-26BA-435C-BABC-314C7E4F23E5@myller.com> Hi all, Patches applied to the 2.1.7 binaries distributed by Robert Harder (http://iharder.sourceforge.net/current/java/ ) are already in the 2.2. Actually in 2.2 the issue with integer types handling seems to be fixed even more extensively than that single patch to 2.1.7 originally did. And yes, Trent has granted me CVS commit access. Thank you. First thing I'm going to focus on is the code quality and clean up: unused variables, invalid pointer usage etc.. Most of this just causing compile warnings - some harmless and some have potential for causing runtime problems. Instead of just blindly committing new changes to CVS, I've been discussing with Trent about the way things have been done in the RXTX CVS before. (how to handle white space patches, what needs to be discussed with the list first, proper locations for new files/ directories/subprojects, "the way things are done in RXTX"). But patches are coming and bugs will be fixed. I hope everyone will continue to submit the bugs they discover to this mailing list. Most important thing is to provide enough info (code;) so that the issue can be duplicated and eventually fixed. -- I > > > On Mon, 7 Sep 2009, Andre-John Mas wrote: >> >> I noticed in the page you posted posted you indicated that you >> patched two files. Did you submit the changes to Jarvi, so they >> could be included in the main code branch? >> > > Ilkka is working with us to get changes in. I'm not sure about > those two patches which may already be in CVS. I'll let him answer > that. > > I've given him write access to CVS and asked him to cc the list non > whitespace changes when they are ready. Right now he is asking > questions off the list regarding cleaning up the Mac and w32 build > files. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 15:35:19 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 17:35:19 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: Thanks for the response. I'll try to get to the electronics store tomorrow to get more serial cables, even if it isn't the problem. I am using a different serial cable than I was in the spring. It's actually a Male/Female cable with a female-female adapter since the old cables aren't around anymore. The hardware's manual says nothing except to use a "Straight cable" but I figured that if it worked in HyperTerminal, it should work in RXTX, right? Anyways, I've also noticed some things that are different between HyperTerminal, RXTX, and a separate program I found that communicates with the device (but doesn't do what I want, which is why I'm rolling my own program) HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and DTR indicators are green Other program - not sure what settings it thinks it's using, but only SPM's RTS indicator is green RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators are on. >From Serial Port Monitor's help files (paraphrased): the indicators display the state of the serial control lines RTS - Request To Send CTS - Clear To Send DTR - Data Terminal Ready Could this be related to the problem? -Nate On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > OK, so: > > 1. It worked in spring but has stopped doing so and > 2. The data all arrives at once when you start hyperterminal. > > Is it possible you're using a different serial cable to connect to the > device, compared to the one you were using in spring? > > If so, the issue might be hardware flow control - that is, your device > might be buffering data because it can't transmit it until your > computer sets 'DTR' or 'RTS' or something like that. > > One way of bypassing hardware flow control is by using cables which > cross over certain wires so that the right signals are always being > sent; it's possible your old cable had these connections but your > current cable doesn't have them. If you can find the old cable, you > could put it back in and see if that fixes things? > > > 2009/9/8 Nathaniel S. Parsons : > > (Sorry if this is a double post, but I sent my original message without > > subscribing, and since this is an urgent problem, I thought I'd resend > after > > subscribing to bypass the moderator limbo zone) > > > > Hi all, > > > > I've asked my question on StackOverflow already, so rather than > copy-paste > > the question here, I'd like to redirect you there. > > > > Short version, I am no longer able to receive anything over RS-232 with > > RXTX, but other programs work fine. I'm definitely sending things, > because > > when I connect with a different program, all the responses to the > commands I > > sent via RXTX arrive all at once. > > > > Everything was fine in the spring, so what could have happened? Windows > > update? > > > > -Nate > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsp25 at cornell.edu Tue Sep 8 18:57:58 2009 From: nsp25 at cornell.edu (Nathaniel S. Parsons) Date: Tue, 8 Sep 2009 20:57:58 -0400 Subject: [Rxtx] Problems with RX In-Reply-To: References: <302aa0340909080030o54b79167n59572de24799eae1@mail.gmail.com> Message-ID: I added a call to setRTS() but nothing changed in Serial Port Monitor, no matter what the argument was. Is this a bug, or did I call the wrong function? I tried to find the c code behind this function, and I think I found it in rxtx-devel\WinCE\gnu_io_RXTXPort.cpp, and that function doesn't look wrong to me. Am I looking at the right function or is the problem somewhere else? -Nate On Tue, Sep 8, 2009 at 4:35 PM, Nathaniel S. Parsons wrote: > Thanks for the response. I'll try to get to the electronics store tomorrow > to get more serial cables, even if it isn't the problem. > > I am using a different serial cable than I was in the spring. It's actually > a Male/Female cable with a female-female adapter since the old cables aren't > around anymore. The hardware's manual says nothing except to use a "Straight > cable" but I figured that if it worked in HyperTerminal, it should work in > RXTX, right? > > Anyways, I've also noticed some things that are different between > HyperTerminal, RXTX, and a separate program I found that communicates with > the device (but doesn't do what I want, which is why I'm rolling my own > program) > > HyperTerminal - set to no flow control, but Serial Port Monitor's RTS and > DTR indicators are green > Other program - not sure what settings it thinks it's using, but only SPM's > RTS indicator is green > RXTX - no matter what flow control I set, only SPM's CTS and DTR indicators > are on. > > From Serial Port Monitor's help files (paraphrased): the indicators display > the state of the serial control lines > > RTS - Request To Send > CTS - Clear To Send > DTR - Data Terminal Ready > > Could this be related to the problem? > > -Nate > > > On Tue, Sep 8, 2009 at 3:30 AM, Michael Tandy wrote: > >> OK, so: >> >> 1. It worked in spring but has stopped doing so and >> 2. The data all arrives at once when you start hyperterminal. >> >> Is it possible you're using a different serial cable to connect to the >> device, compared to the one you were using in spring? >> >> If so, the issue might be hardware flow control - that is, your device >> might be buffering data because it can't transmit it until your >> computer sets 'DTR' or 'RTS' or something like that. >> >> One way of bypassing hardware flow control is by using cables which >> cross over certain wires so that the right signals are always being >> sent; it's possible your old cable had these connections but your >> current cable doesn't have them. If you can find the old cable, you >> could put it back in and see if that fixes things? >> >> >> 2009/9/8 Nathaniel S. Parsons : >> > (Sorry if this is a double post, but I sent my original message without >> > subscribing, and since this is an urgent problem, I thought I'd resend >> after >> > subscribing to bypass the moderator limbo zone) >> > >> > Hi all, >> > >> > I've asked my question on StackOverflow already, so rather than >> copy-paste >> > the question here, I'd like to redirect you there. >> > >> > Short version, I am no longer able to receive anything over RS-232 with >> > RXTX, but other programs work fine. I'm definitely sending things, >> because >> > when I connect with a different program, all the responses to the >> commands I >> > sent via RXTX arrive all at once. >> > >> > Everything was fine in the spring, so what could have happened? Windows >> > update? >> > >> > -Nate >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Tue Sep 8 21:54:26 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Sep 2009 21:54:26 -0600 (MDT) Subject: [Rxtx] rxtx is moving to the clouds Message-ID: rxtx is moving onto a cloud server. You may notice short outages as things move around. So far the following is done. http://rxtx.qbang.org (will redirect rxtx.org there for 2.2) http://bugzilla.qbang.org (bugs) The mail-list is tomorrow night. CVS and FT